invokationFrom an application operation to an inspectable result
Invokation is a developer-first API integration platform for centralizing connection configuration, authentication, execution, visibility, and recovery. It serves both the APIs your company uses and the systems your enterprise clients run. A team with several provider dependencies needs no client or tenant model to use the same layer.
Your application chooses an operation and an explicit profile. The profile resolves the authorized destination, authentication strategy, adapter and mapping version, execution policy, and route. An execution produces a bounded request-response result or a tracked background run. Your team owns the business meaning; Invokation operates the configured connection.
Connections → establish the permitted relationship
Configure endpoints, allowed destinations, protected credential references, environments, scopes, and authentication strategy together. API keys and static bearer credentials need replacement and rotation. OAuth client credentials needs token acquisition and reissuance; delegated grants can need refresh-token rotation and reconnection. A documented custom token endpoint needs request/response mapping and an explicit lifetime contract.
Managed API authentication puts usable-token reuse, expiry buffers, concurrent-renewal coordination, bounded failures, and redacted connection health behind the profile. Your backend authenticates to Invokation; it does not fetch downstream tokens by default. Provider accounts, grants, permissions, and certificate requirements remain necessary. Actual supported methods depend on the adapter and destination.
Profiles → keep provider and customer differences explicit
A profile binds application-defined operations to an implementation. Contracts describe inputs and outputs; adapters implement request/response mappings, field validation, identifiers, pagination, provider overrides, and supported actions. A company’s sendgrid.production connection and a vendor’s client-beta.production connection use the same profile concept with different semantics.
Reusable templates reduce setup. They do not impose a universal email, payment, or enterprise schema. Versioned mappings, synthetic fixtures, normalized error categories, and redacted original errors make changes reviewable. Sandbox and production need distinct credentials and promotion checks. Explore integration profiles.
Execution → choose a lifecycle that fits
Use bounded interactive requests for reads and other operations whose result is needed now. Enqueue background updates or dispatches when completion can happen later. Acceptance means work entered the lifecycle; it is not a completed destination action. Schedules and event triggers extend the model to recurring work.
Inbound webhook handling also belongs to the platform vision: verify authenticity, durably accept delivery, and track processing separately from business side effects. Event receipt does not turn several external APIs into a distributed transaction.
Bound retries, total elapsed time, timeouts, concurrency, queue age, and rate-limit waits. Use backoff and circuit-breaking policies at appropriate failure boundaries. A read, a replace-style write, and an irreversible command deserve different recovery rules. One provider backlog should not exhaust capacity for unrelated connections.
Visibility → understand the failure and the next action
Search per-profile history by environment, operation, trace, and outcome. Inspect attempts, timing, redacted payloads, delivery status, and configuration versions. Alerts should distinguish token expiry, revoked credentials, validation errors, quotas, network failures, and provider unavailability. Audit events describe changes without recording secret values.
Controlled replay can cause side effects. Reuse the original versioned configuration unless an operator deliberately reviews a migration. Destination deduplication depends on its implementation and adapter behavior; there is no universal exactly-once guarantee. Learn about recovery and retry semantics.
Connectivity → use an approved route
For public APIs, ordinary HTTPS may be sufficient. When a destination requires source-address approval, stable shared sets or dedicated outbound allocations provide a documented boundary. Select routing by profile and environment, with region and failover addresses included in handover.
Private-only targets require a separately planned path such as a customer-side agent or approved network connection. An IP allocation neither creates that path nor bypasses authentication, certificates, or enterprise approval. Dedicated addresses do not imply dedicated compute or complete tenant isolation. Compare connectivity options.
Ownership and isolation
The platform design separates organizations, optional customers, connections, credential versions, environments, and operation permissions. Encryption at rest and in transit, restricted runtime access, endpoint constraints, redaction, auditability, and region choices are design requirements. They are not claims of completed audits, certifications, or production SLAs.
Local fixtures, configuration in Git, CI validation, and a future CLI support ordinary developer workflows. Selected operations can also become controlled agent tools under explicit scopes and budgets. SOAP/XML and structured files require deliberate profile implementations; business semantics and proprietary protocols still need engineering.
Start with centralizing a company API stack, the enterprise onboarding sequence, or the developer design preview. Both contexts share operating machinery while keeping application decisions and destination behavior explicit.