API change log

Contract changes that ship with each API version. Review this before setting X-MARMIN-VERSION: 20260507 in production.

How to upgrade (overview)

1. Read the migration guide for your target version below.

2. Test in sandbox with X-MARMIN-VERSION: 20260507 on every request in a workflow.

3. Validate affected endpoints (create, retrieve, list) before production.

4. Roll back by keeping X-MARMIN-VERSION: 20260101 until migration is complete.

Deprecation policy

Older API versions remain available until announced otherwise. When a version is deprecated, this page will list a sunset date and required migration path. Current status: 20260101 baseline and 20260507 latest are both supported.

---

2026-07-07 — Endpoint ID mandatory

Who is affected

Integrators that create or resubmit sale invoices, sale credit notes, purchase invoices, purchase credit notes, or proforma invoices and send accounting_customer_party or accounting_supplier_party.

What changed

FTA substitute reference

For Peppol-registered UAE parties, use the party's 10-digit TIN as endpoint_id with 0235.

Migration steps

1. Audit payloads — ensure every create/resubmit request includes both endpoint_id and endpoint_scheme_id on the party you send.

2. Map transaction types — use the table above for deemed supply, exports, and non-compliant parties.

3. Remove reliance on defaults — do not omit endpoint fields expecting Marmin to apply 9900000098.

4. Test in sandbox with X-MARMIN-VERSION: 20260507.

Affected endpoints

• The Customer party object

• The Supplier party object

• All document create and resubmit endpoints for invoices, credit notes, and proforma invoices

Rollback

Keep X-MARMIN-VERSION: 20260101 until your payloads always include explicit endpoint values.

---

2026-05-07 — `payment_means` shape change

Who is affected

Integrators that create, retrieve, or list sale invoices or purchase invoices and parse or send payment_means.

What changed

Migration steps

1. Requests: Wrap existing payment_means object in an array. One payment method → one-element array.

2. Responses: Read payment_means as an array. Use payment_means[0] where you previously read the object directly.

3. Multiple methods: You may now send several payment methods in one invoice (see Multiple payment modes).

4. Test: Run create → retrieve for each document type you use in sandbox with X-MARMIN-VERSION: 20260507.

Code migration hint

// Before
const code = invoice.payment_means.payment_means_code;

// After
const code = invoice.payment_means[0]?.payment_means_code;

# Before
code = invoice["payment_means"]["payment_means_code"]

# After
code = invoice["payment_means"][0]["payment_means_code"]

Affected endpoints

• Create a sales invoice

• Retrieve a sales invoice

• List sales invoices

• Create a purchase invoice

• Retrieve a purchase invoice

• List purchase invoices

Testing checklist

• [ ] Create invoice with one payment_means item (array with length 1)

• [ ] Create invoice with multiple payment_means items

• [ ] Create invoice with payment_means omitted or null (still accepted on current version)

• [ ] Retrieve returns payment_means as array

• [ ] List content[].payment_means is array on each item

• [ ] Resubmit and retrieve flows use the same X-MARMIN-VERSION header as create

Rollback

Keep X-MARMIN-VERSION: 20260101 on all requests until your parsers handle the array shape. Legacy clients can remain on 20260101 until rollout is complete — that is a deployment choice, not a sandbox test step.

Common errors

Use the Payload examples panel on the right to compare before and after JSON shapes.

Before you upgrade

• Update your code to read and write payment_means as an array.

• Test the endpoints you use in sandbox with X-MARMIN-VERSION: 20260507.

• Use the same header value on every request in a workflow.

• Stay on 20260101 until validation is complete.