APIs and connected services

Understand APIs, integrations and connected services to automate exchanges without sacrificing security or maintainability.

52 articles · Latest article updated

Search covers every article in this topic, including the archive and article text.

Understand the topic

A practical guide to this topic

A connected feature depends on identities, interface contracts, suppliers and failure modes. This category connects API design, security, continuity and the quality of the service users receive. Reliable API integration separates client identity, object permissions and the requested effect. Errors, timeouts and retries should preserve that distinction. An endpoint description is complete only when consumers can recognise a refusal, provisional result and completed operation.

What to examine
  • Identify the calls essential to each journey and their owners.
  • Plan deadlines, errors, safe retries and visible degradation.
  • Rehearse outages, recovery and incident response.
  • Compare actual responses with the documented contract before changing an interface.
  • Test rights on each GraphQL object and field, then bound nesting, lists and aliases by actual cost.
  • Turn a received notification into a unique, traceable business effect recoverable after failure.
  • Separate shared, private and application caches, inspect keys, revalidation and invalidation after access-right changes.
  • Prevent SSRF in downloads, previews and connectors accessing user-supplied addresses.
  • Define budgets, counting identities and recovery behavior when a client reaches a limit.
  • Define ordering, tokens, authorization and recovery when a collection changes during traversal.
  • Control format, resources, access and states from receipt to download.
  • Speed up public responses while preventing cross-account reuse and checking how outdated versions are removed.
  • Separate accepted requests, started processing and final outcomes of long-running operations.
  • Separate produced, received and usable events to explain an outage without treating silence as absence of incidents.
  • Define an iframe or popup messaging contract that rejects unexpected senders, payloads and operation states.
  • Validate paths, links and expanded data before promoting files from an archive.
  • Follow renewal through every termination point and supported client before declaring the change complete.
Useful questions
  • What happens if a provider stops responding?
  • Can a retry repeat an action?
  • What evidence shows recovery works?
  • Which existing clients would a new version affect?
  • Can a resolver return a private field after its parent was allowed?
  • Which bytes are signed?
  • Does no-cache mean nothing is retained?
  • Is HTTPS enough?
  • Is HTTP 429 sufficient protection?
  • Does an empty page mean completion?
  • Is a valid extension enough?
  • Does no-cache mean no storage?
  • Does 202 mean the job is finished?
  • Do three received rows prove three events were retained?
  • Is checking event.origin enough to accept a command?
  • Does a small archive or extraction filter guarantee safety?
  • Is successful ACME renewal enough to close the change?

Illustrative decision example

Situation
Fictional example: these inputs describe no customer or observed result. Two reads are fast, but one still shows old availability after the source changes.
Check
Compare value, version, reading location and time since change. Test invalidation, expiry and source access against the system contract.
Act
Define acceptable freshness per use and monitor divergence. A latency improvement does not establish consistency of served data.

API caching: control freshness, isolation and consistency

HTTP caching: protect personalized responses

IETF — RFC 9111, HTTP Caching

Check recipient and permissions

A signed token does not automatically authorise an object operation. Test issuer, audience, expiry and cross-account access; add expected denials alongside successful cases.

Is a token valid for another API or role actually rejected?

Explore the methods

Read data · verify · decide

API retries: count the end-to-end budget

Four attempts are not four retries. Add call time and waits between calls before comparing with the journey deadline.

Total attempts
4One initial attempt and three retries
Accumulated waits
700 ms100 + 200 + 400
Modelled budget
1,700 ms4 × 250 + 700

Fictional teaching case — figures describe neither CIE nor a client.

Try a retry budget

n × timeout + wait × (2^(n−1) − 1). Doubling waits, without jitter or caps.

Questions to support your decisions

Find answers and practical checks in the analyses in this category.

Explore the archive

Further analysis in this topic beyond the recent articles listed below.

References: data, uses and limitations

Documentation reviewed on .

Threat intelligence: content, exchange and sharingThree distinct functions. STIX 2.1 · Describe. TAXII 2.1 · Exchange. TLP 2.0 · Share. None establishes truth alone. Objects and relationships. Collections and protocol. Permitted recipients. Local validation: origin, period, relevance and permissions.Threat intelligence: content, exchange and sharingThree distinct functionsNone establishes truth aloneSTIX 2.1 · DescribeObjects and relationshipsTAXII 2.1 · ExchangeCollections and protocolTLP 2.0 · SharePermitted recipientsLocal validation: origin, period, relevance and permissions
Threat intelligence: content, exchange and sharing
References: data, uses and limitations
Source and purposeVerified data or benchmarkHow to use itLimitation to retain
MITRE · Common Weakness Enumeration

Name classes of software and hardware weakness.

 A CWE describes a weakness that can contribute to vulnerabilities. It does not represent a particular incident. Connect the weakness to the observed mechanism: input, processing and missing control. Use it to fix the cause and plan regression tests.

Explore the method →

 A keyword in a report alone does not establish the correct CWE classification.
OASIS · STIX 2.1

Describe threat intelligence through structured objects and relationships.

 STIX 2.1 is an OASIS Standard dated 10 June 2021. It defines objects, properties and JSON serialisation. Keep identifiers, dates, provenance and relationships. Check that the recipient interprets the same object type and validity period.

Explore the method →

 A syntactically valid object can still be stale, misattributed or weakly supported.
OASIS · TAXII 2.1

Exchange threat intelligence through an application protocol.

 TAXII 2.1 is an OASIS Standard dated 10 June 2021. It includes service discovery and access to collections. Test authentication, collection permissions, pagination and recovery after interruption. Record which objects were actually received and processed.

Explore the method →

 TAXII transports data; it replaces neither the content model nor assessment of reliability.
MDN · Cookie boundaries

Understand session-cookie scope and SameSite boundaries.

 Secure, HttpOnly, SameSite and the __Host- prefix address different risks. A site can include multiple origins. Test external navigation, subdomains, provider returns and authenticated operations separately.

Explore the method →

 Cookie configuration does not replace CSRF checks or server-side authorisation.

Identity: factors, sessions and recovery

Identity APIs: separate authentication and authorisation

A valid token identifies a session or identity under its protocol. It does not automatically grant access to every business object. Recovery and revocation must be checked on the consuming backend.

  • Check applicable issuer, audience, expiry and permissions.
  • Replay access to an unauthorised object and a revoked session.
  • Record useful decisions without logging authentication secrets.

Open the authenticator and recovery comparison →

Sources consulted on · NIST SP 800-63B-4 · final publication NIST · Authenticator Event Management W3C · WebAuthn Level 3

ETag, HTTP caching and concurrent updates

Specify conflicts in the API contract

The contract should explain which validator accompanies a representation and how clients handle refusals.

  • State whether PUT requires a conditional field and when 428 is issued.
  • Document strong If-Match, 412 and the conflict-resolution journey.
  • Support HEAD and 304 without content and test SDK behaviour.

Explore ETag comparisons and the simulator →

References reviewed · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3

Retry-After: waiting, budgets and retry decisions

Specify permission to repeat before retry timing

Retry-After describes waiting. The contract must also define replayable operations, keys, versions and unknown-result states.

  • State whether the field is seconds or a date and how clients handle absent or invalid values.
  • Name the retry controller and global budget to prevent overlapping attempts.
  • Retain parameters, context and the idempotency window without generalising Stripe to every API.

Explore Retry-After and the retry model →

References reviewed · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS

Explore the CISA KEV catalogue

One identifier can span several technical layers

An entry may concern a library, server or component embedded in an appliance. Search the exact name, known dependencies and the distributed product’s advisory. Catalogue aliases are not a complete list of affected versions.

  • Connect the CVE, component supplier and final-product supplier.
  • Check version, configuration and execution path in the authorised environment.
  • Do not infer remediation from an empty search result.

Explore the catalogue and method →

CISA KEV · 2026.10.21 · Documentary review : 2026-10-22

Extensions: permissions and access

Robust authentication does not describe extension access

Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.

  • Test approved extensions in a profile dedicated to sensitive operations.
  • For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
  • Distinguish session revocation, token revocation, extension disablement and native-component removal.

Read the permission directory and manifest examples →

Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent

Syslog codes and collection evidence

Normalisation must preserve event meaning

In a distributed API, a PRI integer combines two codes. An opaque conversion may lose the message family or reverse severity. Test collection with identified events before inferring operational reliability.

  • Keep facility, severity and raw value in separate fields.
  • Distinguish source time, reception time and search availability.
  • Expose rejected events, truncation, loss and conversion rules.

Read syslog codes and try the PRI calculation →

IANA · syslog Parameters · Registry updated 2016-04-26 · consulted 2026-10-23

ASD ACSC and partners · Best practices for event logging and threat detection · Published and reviewed 2024-08-22 · consulted 2026-10-23

API errors: types, statuses and evidence

Include errors in contract tests

A new type URI, removed extension or changed status may alter consumer behaviour. Failure examples are part of the contract alongside successful responses.

  • Replay existing clients against representative refusals.
  • Check tolerance of unknown extensions and localised text.
  • Document migration of a problem identity and actually observed use.

Explore problem types and eight fictional responses →

IETF · M. Nottingham, E. Wilde, S. Dalal · RFC 9457 · July 2023 · obsoletes RFC 7807 · §3.1, §3.2, §4.2, §5

GraphQL: errors, lists and partial data

GraphQL API: contract, access and reading experience

Extend API checks with partial-response acceptance cases, field-access tests and a resource budget specific to the service.

  • Compare absent data, partial data and data: null.
  • Keep the original path even when a parent becomes null.
  • Test permissions, quotas and interface states separately.

Explore GraphQL responses and nullability →

GraphQL Specification · September 2025 · Published edition · September 2025

API deprecation and retirement

Plan retirement beyond the version number

A published version does not say when consumers need to migrate. Connect deprecation announcements, retirement dates and existing-client tests.

  • Distinguish Deprecation, Sunset and policy links.
  • Check that Sunset does not precede Deprecation when both dates are provided.
  • Measure remaining consumers and validate the replacement before cutover.

Compare deprecation and retirement announcements →

IETF · RFC 9745 · Deprecation · Standards Track · March 2025 · §2–5 · consulted 2026-10-23

IETF · RFC 8594 · Sunset · Informational · May 2019 · §3–5, §8 · consulted 2026-10-23

Reference material

Primary guidance published by the organizations responsible for these methods and standards.