01
Public + partner APIs
REST, GraphQL, gRPC APIs for external consumers: with versioning policy, deprecation calendars, rate limits, contract tests, and developer portals that aren’t Swagger UI hosted on a 404.
Custom Software · FORGE
API & Integration.
APIs, middleware, event-driven architecture, and iPaaS implementations, engineered with documented contracts, retry semantics, idempotency, and explicit failure modes. Not the cron job nobody owns.
- Practice
- Custom Software
- Department
- FORGE
The problem
Most integration platforms become the system of unrecorded record.
The pattern across integration engagements: a middleware layer that started as one cron job, grew into seventeen, none of which have idempotency keys; APIs without contracts, where a downstream change ships on Tuesday and breaks four upstream consumers by Wednesday; event buses with no schema registry where producers publish whatever they feel like and consumers parse defensively; iPaaS workflows that do production-critical work but live in a low-code editor that nobody can diff in code review. The integration layer becomes the system of unrecorded record, and audit time arrives.
Prosigns ships integration platforms with the contracts, retry semantics, idempotency, and operational discipline as primary scope. APIs are versioned and documented. Events have schemas in a registry. Workflows are in source control with diffable history. Failure modes are explicit and tested, not discovered at 3 AM. The result: integration that compliance trusts, operations can debug, and the next engineer can extend.
Where it ships
6 use cases, in production.
Specific applications we’ve built and operated. Not speculative: every example below is grounded in a real shipped engagement.
- 02
Internal service APIs
API gateways and service contracts for internal microservice meshes. Service-to-service auth, schema registry, contract testing in CI, observability per route.
- 03
Event-driven architecture
Kafka / EventBridge / Pulsar implementations with schema registry, exactly-once semantics where the workload requires it, replay tooling, and DLQ handling that’s actually wired into operations.
- 04
iPaaS implementation
MuleSoft, Workato, Boomi, Azure Logic Apps: implemented with source control, test coverage, deployment pipelines, and operational discipline. Not click-ops in production.
- 05
Legacy system bridges
SOAP-to-REST bridges, mainframe-attached APIs (z/OS Connect), middleware in front of in-house Java / .NET / AS/400 systems. Documented contracts, fallback for source-system outages.
- 06
Webhook + async fan-out
Webhook delivery with retries, signing, replay, and observability. Async event fan-out to multiple consumers with per-consumer failure isolation.
How we engage
4 phases, named in the SOW.
Each phase has a deliverable, an owner, and an acceptance criterion. Not slogans, operating rules.
- 01
Contracts before code
OpenAPI / GraphQL SDL / Protobuf / AsyncAPI schemas designed and reviewed with consumers before implementation begins. Mock servers stand up against the contract so consumers can build in parallel.
- 02
Idempotency + retries from day one
Every write endpoint has an idempotency key strategy. Every async consumer is replay-safe. Retry policies with exponential backoff and jitter, capped retries, and DLQs wired into incident response.
- 03
Schema registry + versioning
Events carry schema versions; the registry enforces compatibility. APIs version explicitly with deprecation calendars consumers can plan against. No breaking changes shipped without consumer migration support.
- 04
Observability per route + per event
Distributed tracing across hops, per-route latency and error budgets, per-event-type throughput and lag dashboards. Operations can answer 'what changed at 14:32?' in minutes, not hours.
Capabilities
What’s in scope.
- REST, GraphQL, gRPC API design and implementation
- API gateways: Kong, AWS API Gateway, Azure APIM, Apigee
- Event-driven: Kafka, AWS EventBridge, Pulsar, Azure Service Bus, NATS
- iPaaS: MuleSoft, Workato, Boomi, Azure Logic Apps with source control discipline
- Schema registries (Confluent, AWS Glue) + contract testing in CI
- Webhook delivery with signing, retries, replay, observability
- SOAP-to-REST bridges, mainframe-attached APIs, legacy system facades
- Distributed tracing, structured logging, per-route SLOs
Stack
Tools we use in production.
- API frameworks
- Next.js / HonoFastAPISpring BootASP.NET CoreApollo / GraphQL Yoga
- Gateways
- KongAWS API GatewayAzure APIMApigeeTyk
- Event platforms
- Apache KafkaAWS EventBridgeApache PulsarNATSAzure Service BusRabbitMQ
- iPaaS
- MuleSoft AnypointWorkatoBoomiAzure Logic AppsAWS Step Functions
- Schema + contracts
- OpenAPIGraphQL SDLProtocol BuffersAsyncAPIConfluent Schema Registry
- Observability
- DatadogOpenTelemetryHoneycombSplunkPrometheus + Grafana
Selected work
Quantified outcomes, not adjectives.
Common questions
Asked before the first call.
- 01
REST, GraphQL, or gRPC?
REST for public APIs and partner integration where wide HTTP-tooling support matters. GraphQL when the consumer is a complex frontend with diverse query needs and the team can absorb the operational complexity. gRPC for internal high-throughput service-to-service. We tell you which fits, and often the answer is 'all three, in different parts of the architecture.'
- 02
Should we use an iPaaS or build custom integration?
iPaaS wins for many enterprise integration patterns: connector libraries, GUI workflow editors, and operational tooling have real value. Custom code wins when the workload has high throughput, sub-second latency requirements, deep custom business logic, or the iPaaS pricing model breaks at scale. We’ve built both; we’ll tell you which fits your case.
- 03
How do you handle versioning and breaking changes?
Versioning policy in writing before launch. Deprecation calendars consumers can plan against (typically 6–12 months for breaking changes). Compatibility tested in CI against pinned consumer contracts. We don't ship breaking changes without consumer migration support.
- 04
What about authentication and rate limiting?
OAuth 2.0 + OIDC for human-attached flows, mTLS or signed JWTs for service-to-service, API keys with scoping for partner / third-party integration. Rate limits per consumer, per route, with backoff hints in headers and explicit 429 handling.
- 05
How do you ensure data integrity in event-driven flows?
Idempotency keys on every write endpoint. Outbox pattern for transactional event publishing. Schema registry with compatibility enforcement. Replay tooling for reprocessing events from a known good point. Reconciliation jobs comparing source-of-truth state against event-derived state, alerting on drift.
- 06
What does an integration engagement cost?
Discovery + ADR set: 3–5 weeks, $40K–$120K. Single-domain integration platform: 3–6 months, $200K–$700K. Multi-domain event mesh / iPaaS implementation: 6–12 months, $500K–$2M. Public API platform with developer portal: 4–8 months, $300K–$1M. Managed Services: $25K–$150K monthly retainer.
Within Custom Software
Other capabilities in this practice.
Talk to us
Bring an API & integration problem. We’ll bring a senior engineer.
A senior engineer plus the FORGE department lead joins the first call. No discovery gauntlet, no junior reps.