Skip to main content

Integration checklist

Use this before calling a new or changed service integration done.

Shape​

  • The service id is final and matches the intended public contract.
  • service_sources and transports both reflect the same ingress set.
  • Any action that downstream nodes bind from exposes result_event.
  • supports_nodes is what you expect: condition, lookup and mapping by default, plus rate-limit only when enabled.

Wiring​

  • TRIGGERS_NATS_URL is present everywhere the service runs.
  • TRIGGERS_KAFKA_BROKERS is present anywhere Kafka ingress is declared.
  • Kafka ingress has a viable ownership path in that environment: either the SDK runtime can create the canonical triggers_v2_<service>_inbound topic, or that same canonical topic is pre-provisioned out of band.
  • Any released flow that retargets Kafka delivery to a non-canonical topic uses a topic that already exists, because the SDK will not create it; if it is missing, reconcile fails closed and Kafka ingestion stays unavailable until the topic exists or the flow is corrected.
  • Any configured TRIGGERS_KAFKA_INGRESS_TOPIC_* overrides parse cleanly.
  • Anywhere dedup or rate limiting is enabled, the SDK Redis contract is satisfied with either TRIGGERS_REDIS_URL, TRIGGERS_REDIS_URL_SECRET_NAME, or host/password inputs plus optional TRIGGERS_REDIS_DB.
  • Any Redis *_SECRET_NAME path also has KEY_VAULT_URL.
  • HTTP services have a correct public manifest target, not just a listen socket.

Runtime​

  • GET /api/v2/services/<service> shows the new manifest and the service is online.
  • Heartbeats are arriving.
  • One released flow has been exercised end to end.
  • Failure paths produce the expected retry or DLQ behavior.

Docs and examples​

  • Project-local docs match the current API surface.
  • docs_ui matches the source docs.
  • Example code uses the same ingress names and canonical targets as production code.