Integration and API Architecture
Commerce exposes REST, SOAP (legacy), GraphQL, and async messaging. Service contracts annotated in webapi.xml define REST/SOAP endpoints; GraphQL requires a schema.graphqls declaration and resolvers. Know authentication types: integration tokens (OAuth 1.0a for REST admin), customer tokens, admin tokens, and session-based auth for storefront. Async integration uses the message queue framework: communication.xml declares topics, queue_communication.xml binds consumers, and queue_topology.xml defines exchanges and queues.
Traps: assuming REST and GraphQL expose identical data (they do not; GraphQL requires explicit schema and resolver work), confusing synchronous webapi with async consumers, and forgetting that extension attributes are how third-party data rides along on core service contract responses. Also know rate limiting, the searchCriteria query parameter format for REST, and that bulk APIs exist for high-volume operations.
Worked example
Requirement: "Push order data to an ERP without blocking checkout." Do not call the ERP synchronously in the order placement flow. Instead, publish an order-created message to a topic via the message queue publisher, declare a consumer in communication.xml and queue_consumer.xml, and let a cron-driven consumer process the queue with retry and dead-letter handling. This decouples checkout latency from ERP availability.
Rule of thumb: anything that talks to an external system during a customer-facing request should be a candidate for async messaging unless the response is required to complete the transaction.