invokationYour product has one job. Its API dependencies have many.
A fictional product takes a payment-status read, sends a transactional notification, posts an operational message, and synchronizes a record with a custom API. Its business logic decides when those actions belong together. Each connection still has its own credentials, environments, quotas, response shapes, failure modes, and support procedure.
Invokation puts those connections behind explicit profiles and a shared execution model. A backend calls an application-defined operation; the profile selects authentication, adapter version, execution policy, and route. This works for one company using several providers. An enterprise-client identity is optional.
Stripe, SendGrid, Twilio, Slack, Salesforce, and GitHub are recognizable examples of APIs a team might use. They illustrate compatibility patterns, not shipped connectors or endorsements. A payment read and an email dispatch keep their different semantics. Moving between providers may require adapter and application changes.
Four connections, one place to operate them
| Connection | Application-owned operation | Execution choice | What needs attention |
|---|---|---|---|
| Payment provider | payments.getStatus | Bounded interactive read | Permissions, ambiguous earlier writes, provider state |
| Transactional email | messages.send | Queued dispatch | Acceptance versus delivery, duplicate side effects |
| Team messaging | notifications.publish | Queued operation | Channel scope, quotas, delivery result |
| Custom enterprise API | records.list | Interactive read or scheduled job | Token endpoint, mapping version, network approval |
These names belong to the fictional application. They are not a universal payment, messaging, or record schema. The adapter translates each operation into an allowed provider interaction and validates the result. Unsupported actions return an explicit error instead of a plausible empty response.
Configure the connection once
A profile such as stripe.production or sendgrid.production binds an adapter to protected credential references, an environment, permissions, and a bounded execution policy. A custom API can instead use a configured authentication endpoint and token-lifecycle policy. Callers keep using the same developer interface without fetching downstream tokens themselves.
Managed API authentication covers protected storage, expiry buffers, coordinated renewal, and reconnect-required states. Credentials remain scoped to approved destinations. Authorizing Invokation does not create provider accounts or grant permissions the developer never obtained.
Keep decisions in the application
Your application decides whether a payment is sufficiently confirmed, whether a notification should be sent, and what a record’s status means. Integration infrastructure executes those authorized operations, records outcomes, and exposes failures. It does not turn several remote APIs into one database transaction.
Inbound webhook handling and schedules belong to the platform vision alongside outbound requests. A durable event receipt is distinct from successful business processing. An accepted queued dispatch is distinct from delivery. These distinctions should survive normalization, logs, and dashboards.
Recover with evidence
Inspect a trace by profile, operation, environment, and outcome. Separate a provider outage from a revoked credential or invalid request. Redact sensitive payload fields before storage. Retry only when the operation policy and destination behavior permit it; investigate unknown write outcomes before replaying.
Separate queues and concurrency budgets prevent a slow provider from occupying every worker. Centralization also introduces an additional failure domain and network hop. Choose bounded timeouts, backpressure, and ownership deliberately; see the centralization architecture guide for tradeoffs.
Integration requirements checklist
Use this checklist when adding a connection. Record references and categories, never secret values or confidential endpoints in a shared research document.
| Requirement | Questions to settle |
|---|---|
| Provider and owner | Which dependency, which team, and who responds to failure? |
| Operations | Which reads and writes, contracts, unsupported actions, and business rules? |
| Authentication | API key, OAuth, custom token endpoint, or a supported session mechanism? |
| Credentials | Who grants permission, where is the secret reference, and who rotates it? |
| Token lifecycle | Approved auth endpoint reference, lifetime contract, buffer, renewal and reconnect rules? |
| Environments | Sandbox and production accounts, scopes, adapter versions, and promotion gates? |
| Quotas | Limit scope, concurrency, Retry-After behavior, and fairness? |
| Incoming events | Signature verification, acknowledgment, duplicate and ordering policies? |
| Side effects | Idempotency support, ambiguity handling, reconciliation, and replay approval? |
| Sensitive data | Field redaction, retention, authorized access, and deletion? |
| Observability | Trace correlation, final outcome, alerts, owner, and runbook? |
| Connectivity | Ordinary public HTTPS, approved source addresses, or a separate private route? |
The copyable template below is intentionally a requirements document, not an executable profile. Adapt it to your own repository and review it with the owning team.
Start with the dependency that keeps interrupting you
A small, stable API call may need only a good direct adapter. A recurring authentication failure, scattered logs, or duplicated recovery code is a stronger reason to centralize. Compare the platform ownership model, explore the developer design preview, or join early access with the connection problem you want to solve.