Platform engineering integrations and automations

The patterns underneath the business processes: API facades, change data capture, webhook delivery and the move off batch files.

4 guides · Built with Tray Headless

What this work has in common

These guides describe shapes more than named business processes, and they sit underneath the rest of the library. A facade, a change capture pipeline, a webhook fan-out and a migration off a batch file are each something several teams were about to build separately, in slightly different ways.

They are also where the expensive mistakes are made. A decision about retries, idempotency or identity at this layer is inherited by every workflow built on top of it. A facade that loses the caller’s identity means every downstream audit log shows a service account. A fan-out without replay means a consumer that was down for an hour has a gap nobody can fill.

The systems vary more here than in the other categories: a Postgres or Snowflake database, an SFTP server, Datadog for monitoring, Stripe or Zendesk as webhook sources, and whichever CRM and ERP the consumers need. What stays the same is the set of guarantees: one contract per consumer, ordering and deletes preserved, delivery that can be retried and replayed, and a cutover you can prove is safe.

The four guides cover the API facade, change data capture, webhook fan-out and the migration from SFTP batch files to APIs. They pair with the data operations guides, which build on the same capture and delivery patterns.

Each one is written so the pattern can be built once and reused, with the first consumer as the worked example.

Where integration platforms break

Every consumer calling every system

Six teams each integrate with the CRM, the ERP and the billing system, each with its own credentials and its own retry logic. When an upstream API changes, six things break. A facade gives consumers one contract and absorbs the change in one place.

Polling a timestamp

Querying for records modified since the last run misses deletes, misses changes made in the same second, and falls over when the clock on the source drifts. Reading the change log keeps order and deletes intact.

Acknowledging after the work

A webhook receiver that does all the downstream work before it returns a 200 times out, and the sender retries, and the work happens twice. Verify the signature, acknowledge, then fan out with a retry per consumer.

Cutting over before month end

A batch file carries rules nobody wrote down: a sort order, a field that means two things, a record that only appears at quarter end. Run old and new in parallel and compare the output through a full month end before switching off the file.

The platform engineering guides

Each one is the design, the sequence it runs in, the prompts that build it, and what changes when it runs in production.

The systems involved

The applications these guides read from and write to, most used first. Each links to its connector page.

Snowflake (4 guides)
Datadog (3 guides)
Slack (3 guides)
Salesforce (2 guides)
NetSuite (2 guides)
Zendesk (2 guides)
PostgreSQL (1 guide)
Stripe (1 guide)
Jira (1 guide)

Connections these guides build

Solutions for platform engineering

The solution pages for this work, with the customer stories behind them.

Data integration with Tray.ai Integration without the integration backlog.
Embedded integration with Tray.ai An integration marketplace that lives inside your product.
Partner integrations with Tray.ai More integrations. Less engineering.