Twelve ways in. Twelve ways back out. One consistent flow.

The first connector most teams meet.

Twelve connectors come online for a customer. Six read the world into Polymr, six write back out to your ERP and to vendors. Where the destination system can recognise a duplicate write on its own, we use that. Where it cannot, Polymr keeps its own check so a retry never creates a second PO. Everything in between follows one shared pattern. The view below is the connector most teams meet first: one vendor email opened next to what Polymr pulled out of it, with a confidence score and a link back to the exact place each field came from.

Messy inputs come in. Clean, structured records come out.

Every read connector follows the same three steps. Pull data from the source on its own schedule. Read it against the rules for that source. Hand off a clean record with a confidence score on every field and a link back to the original document. The connector never writes anywhere on its own; the next step in Polymr decides what to do with the record.

Keeping the reading step separate from the decision step means we can replay any connector. Re-running last Monday's inbox against today's improved reader produces today's records without going back to the original source. Each connector ships with a simple list of every kind of record it can produce and the fields each one needs. Confidence scores follow the data downstream, so Polymr refuses to act on anything below the threshold for that field.

Safe retries. The destination refuses the duplicate, not us.

Every write back to your ERP or a vendor carries a key the destination can recognise. The key is not a Polymr ID. It maps to whatever the receiving system uses for a unique record: a PO line in SAP, an externalId in NetSuite, a clientToken in QuickBooks Online, the control numbers on an EDI document. If the same write fires twice with the same key, the destination flags it as a duplicate instead of creating a second record. Polymr does not have to track whether the first attempt succeeded; the destination tells it.

When the destination does not support a key like that, the write connector keeps its own ledger of what has already been sent and refuses to send the same payload twice. The workflow side cannot tell the difference between the two modes. Before a connector goes live, an operator can run it in shadow mode and inspect every payload first. Switching from shadow to live is an explicit action with a reason captured.

Twelve connectors. Six in, six out.

The read connectors feed the shared picture of the plant. The write connectors push approved actions back out. Where the destination can recognise a duplicate write on its own, we use that; where it cannot, Polymr keeps its own check. The map below names every connector with its typical lag and how duplicate protection is handled.