Using the API

API Keys

Koalafi has both protected apis and unprotected apis. For unprotected apis we authorize your request based on a Public Dealer ID and for protected we use a Private API key that are passed up via a header in the request. Using these values will allow you to securely access our apis.

Obtaining your API Keys

During dealer onboarding you will be issued a public dealer id and a private api key. In order to call our unprotected apis you will need to provide this value in a public-dealer-id header for each request. For more information on onboarding, view Onboard with Koalafi

{  
  "public-dealer-id":"<public dealer id value>"  
}

For our protected APIs you will need to add a private-api-key header to the protected request.

{  
  "public-dealer-id":"<public dealer id value>",  
  "private-api-key":"<private api key value>"
}

🚧

Coming Soon ...

We are currently building out a public postman collection containing all our important queries. In the meantime, you can use the example below and our docs as a guide to creating your custom queries.

Example Response

Whenever you query our endpoints you will always get back two objects - the success object and the error object. In the example below, sampleField represents the success object and sampleMutationErrors represents the error object. Always check the length of the error object before moving forward with the successObject. If there are no errors returned, the length of the error object will be 0.

mutation {
  sampleMutation(
    input: {
      sampleFakeBoolean: true
    }
  ) {
    sampleField
    sampleMutationErrors {
      __typename // include this to get the error type back
      ... on ErrorA { // optional
        message
      }
      ... on ErrorB { // optional
        message
      }
    }
  }
}

In the above example, we would check the length of sampleMutationErrors. If length is 0, the mutation was a success, and we can use our sampleField. If length > 0, the __typename field can be used to see the type of error returned. Including the optional ... on ErrorA { message } fragment in our query, we can use that message to get more details on the error that occurred. A comprehensive view of possible errors is in our API Schema.