1. Home
  2. Getting Started
  3. Data and Dropsource
  4. API Requirements

API Requirements

To connect to external data in Dropsource, you need to use an API that is documented using a Swagger (OpenAPI) specification. In order to work in your Dropsource project, both your API and your specification will need to meet a few requirements, as outlined below.


Your API can use the following transfer protocols, as indicated in the spec file schemes field:

  • http
  • https


Your API can consume any of the following MIME types, as indicated in the spec file consumes field:

  • application/json
  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

These MIME types indicate the types of request parameter your app will be able send to the API.


Your API must return JSON data, as indicated in the spec file produces field, as application/json . In your Dropsource project, you will be able to display or process responses from your API requests as long as they are structured in JSON.


Each path in your API must return predictable data structures – if a response field in a request can return different types when it executes, you will not be able to use that endpoint in Dropsource. For example, a field that is sometimes an object and sometimes a string would not be compatible with Dropsource.


Any parameters sent with your API requests from Dropsource must be clearly defined as one-to-one relationships between your app and each field. For example, you cannot build multiple inputs from the app into a single parameter field using concatenation.

  • Valid query string: ?query=Hello&limit=1
  • Invalid query string: ?data={query: Hello, limit: 1}

Dropsource supports the following parameter types (as indicated in the spec file parameters > in fields):

  • query
  • path
  • formData
  • body

Dropsource does not support the following:

  • parameters in the form of an array (even as a property of a definition in a request body)
  • header parameters


Your API can use the following security schemes for authenticating requests (as indicated in the spec file security and securityDefinitions fields):

  • OAuth2 Password flow (not implicit)
  • API key (in query or in request header)
  • Basic (username and password)
ⓘ Note

See the API Tools section for guidance on setting up your API and authoring your specification.

Was this article helpful to you? Yes No 4

How can we help?