This functionality is available on all plans.

Integrating with Stedi

Virtually every aspect of Stedi is accessible via API, allowing you to programmatically accomplish almost anything you can do in the UI. This includes setup and configuration of trading partners, connections, and other settings, as well as sending and receiving EDI.

In practice, most integrations only need to implement two integration points:

  • A method in your system for calling the generate EDI endpoint when you need to send a transaction to a trading partner
  • A method in your system for receiving destination webhooks from Stedi when you receive a transaction from a trading partner, or when an exception occurs.

However, if you need to automate a more complex workflow – for example, if you’re using Stedi to build native EDI functionality into a SaaS platform – you can use the full suite of APIs to create and manage trading partners and more.


You need an API key to use any Stedi API. You pass the API key in the Authorization header of every request and it determines which resources you can access.

You can create your API key using the UI.

API key access

In accounts with an Unlimited or Unlimited + Cloud plan, an API key grants access to all resources belonging to an account.

In accounts with an Enterprise plan, members can be assigned to roles with different permissions. API keys inherit the permissions of the account member who created them and keep those permissions even if the creator’s role is later updated.

Passing the API key

Every request you send needs to include an API key. You pass the API key in the Authorization key, prefixed with the word Key. For example, if your API key is Jclcke.ZHqS3demo4dS16XZ1KeyBY7 and you want to retrieve a list of all your API keys, you make the following request.

Authorization: Key Jclcke.ZHqS3demo4dS16XZ1KeyBY7


When you request a list of resources, the response may contain a subset of available responses. In that case, the response will include a key called next_page_token. To retrieve the next page of results, repeat the request, but add the query parameter page_token and give it the value you received in the response.

For example, say you retrieve a list of API keys.

Authorization: Key Jclcke.ZHqS3demo4dS16XZ1KeyBY7

The result contains a list of keys and a token for the next page.

  "results": [ ... ],
  "next_page_token": "2t7M75ZN1w4OnYFKKT0SUkT95w_ULzPR"

You can then request the next page of results like this:

Authorization: Key Jclcke.ZHqS3demo4dS16XZ1KeyBY7

As long as the response contains next_page_token, there are more results available. If a response doesn’t contain next_page_token, then you’re on the last page.

Error responses

If you make a request that the API can’t fulfill, the response code will be in the 4xx range and the response body will contain the following two fields.

  • error – A code indicating what went wrong.
  • message – A human-readable message describing what went wrong.

You can use error to write code that handles the error and you can use message when you’re debugging the problem yourself. If a response needs to report multiple errors, it will include an array called errors, but even in that case, the error and message fields will be available at top level.

It’s possible for a response to contain both a result and an error. This happens when something went wrong, but the API is able to give a partial or best-effort result.

API upgrades

We strive to maintain backwards compatibility. The following changes are considered backwards compatible:

  • New API resources
  • Additional optional parameters to API requests
  • Additional fields in API responses
  • Changes in the order of properties in API responses
  • Changes in human-readable error messages
  • Downgrading mandatory parameters to optional parameters.

When we introduce a breaking change, we release a root-level, dated version.

Was this page helpful?