Integration record
Connect what the business already uses.
I map the available interfaces, write the data contract, and make each handoff visible before another system acts.
Follow the route- 01ReceiveAPI · webhook · event · file
- 02Translateauth · validate · map · route
- 03Actsync · notify · decide · hand off
The connector is not the first decision.
A vendor name says very little about the route. I first establish what can be accessed, who may use it, what data must move, and what happens when the destination is unavailable.
- Interface
- The API, webhook, event, database, file, or other contract that is actually available.
- Identity
- The account, role, token, and approval boundary behind each action.
- Data
- The fields that enter, the fields that leave, and the record that remains between them.
- Failure
- The retry, rejection, alert, or human handoff used when the normal route cannot finish.
Every route has three jobs.
The systems can change. The route still needs to receive a trustworthy input, translate it into the destination contract, and make the result visible.
- 01
Receive without guessing.
Accept the incoming event through its declared interface. Check its source, required fields, size, and identity before it enters the working flow.
A validated input with a traceable source.
- 02
Translate the contract.
Map names, types, permissions, and business rules into the form the next system expects. Reject incomplete or ambiguous data instead of silently reshaping it.
A destination-ready request with a recorded mapping.
- 03
Act and leave a record.
Send, store, notify, or hand off the result. Capture enough evidence to tell whether the destination accepted the action and what should happen next.
A completed action, clear failure, or named human handoff.
Different vendors can stay different.
A useful integration does not force every tool into one platform. It gives each system a defined role and makes the crossing points explicit.
Cloud + data
Compute, storage and databases
- Amazon Web Services
- Google Cloud
- Microsoft Azure
- Supabase
- Hetzner
Business apps
Commerce, payments and workspaces
- Shopify
- Stripe
- Notion
- Clerk
- Resend
Developer ecosystem
Code, deploys and runtime
- GitHub
- Docker
- Vercel
- Cloudflare
- 01 ReceiveAPI · webhook · event · file
- 02 Translateauth · validate · map · route
- 03 Actsync · notify · decide · hand off
AI providers
Models, retrieval and tool calls
- OpenAI
- Anthropic
- Google Gemini
- xAI
- Groq
- OpenRouter
Chat systems
Messages, media and human handoff
- Telegram
- Discord
- Slack
Other systems
A usable contract is the starting point
- REST
- GraphQL
- SOAP
- SFTP
- CSV
The route must carry its own limits.
- Credentials
- Use the narrowest account and permission set that can complete the action.
- Vendor limits
- Treat quotas, rate limits, payload limits, and policy as part of the design.
- Irreversible actions
- Keep payments, deletions, publication, and other material actions behind an explicit approval boundary when the risk requires it.
- Recovery
- State which failures can retry safely, which must stop, and which need a person to resolve them.
Where this appears in real work.
Custom Cap BD
A shared commerce and factory engine connects artwork, orders, invoicing, production tracking, and several buyer and supplier surfaces without turning them into one undifferentiated application.
View Custom Cap BD
Marina Rewards
A React and FastAPI product coordinates background workers, Postgres, Redis, and AWS services across member, partner, kiosk, and operator workflows.
View Marina RewardsShow me the two systems that need to cooperate.
Send the trigger, the data that must move, the destination, and the failure you cannot afford to hide.