Key takeaways
- Post a document as raw X12 or as JSON to one endpoint. JSON is turned into X12 with your partner’s delimiters, and either way the document is checked against the partner’s guide.
- Validation errors come back as structured data in a
422response, before anything is sent. - Documents that come in can be pushed to your URL as webhooks, in JSON or XML, reshaped by a mapping if you want.
Why raw EDI is hard to code against
An X12 file identifies data by position, not by name: the purchase order number is simply the third element of BEG. Each trading partner then adds its own rules on top of the standard, documented in a PDF. Writing and validating that by hand, for every partner, is where integration projects stall. (If X12 is new to you, read the X12 file format, explained.)
The API at a glance
| Endpoint | What it does | Scope |
|---|---|---|
GET /me | Identifies your account and the key’s scopes | — |
POST /documents | Sends an outgoing document, as X12 or JSON | write:documents |
GET /deliveries | Lists documents sent and received, with their status | read:deliveries |
GET /partners | Lists your trading partners | read:partners |
GET /guides | Lists the guides your documents are checked against | read:guides |
Calls are authenticated with an API key in an Authorization: Bearer header, and each key carries only the scopes you give it. Keys are limited to 600 requests a minute.
curl "https://app.weredi.io/api/v1/deliveries?status=failed&direction=outbound" \ -H "Authorization: Bearer $WEREDI_API_KEY"
Sending a document
POST /documents accepts either a raw X12 document or a JSON representation of it. JSON is converted to X12 using the delimiters in your partner’s guide, and the result is checked against that guide before it goes anywhere.
- Errors block the send. The response is a
422 validation_failedwith each finding, so your code can show or fix it. - Warnings don’t. The document goes out, and the warnings come back with the response.
- You stay in control. A flag lets you override validation when your partner has asked for something its guide doesn’t say.
Receiving documents with webhooks
For documents coming in, set up an automation with a webhook action: when a document arrives, filtered by type and partner if you like, Weredi posts it to your URL as JSON, XML or form fields. A mapping can reshape it into exactly the payload your application expects. Each call’s request and response are kept with the document, so a failed delivery to your endpoint is easy to investigate.
Which plan?
The REST API and webhooks are part of Weredi Plus and Enterprise, and are on during the 14-day free trial.
Questions
Does Weredi have an EDI API?
Yes. The Weredi REST API lets you send documents, list deliveries with their status, and read your partners and guides, with scoped API keys.
Can I send JSON instead of X12?
Yes. POST /documents accepts a JSON representation of the document and converts it to X12 with your partner’s delimiters, or you can send raw X12.
Does the API validate documents before sending them?
Yes. Each document is checked against the partner’s guide; errors return a 422 response with the details and nothing is sent, while warnings don’t block.
How do I receive incoming EDI documents in my application?
Use an automation with a webhook action: Weredi posts each incoming document to your URL as JSON, XML or form fields, optionally reshaped by a mapping.