[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-tolerant-reader::en":3,"gloss-cluster-tolerant-reader::en":26,"gloss-next-tolerant-reader::en":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"tolerant-reader","integration","Tolerant Reader","A tolerant reader is a client written to read only the parts of a response it actually needs and to ignore everything else, so that an addition on the other side is not an outage on yours. It is the consuming half of the rule that additive changes should be safe: a provider can only add a field without breaking anyone if the people reading it are built to shrug at fields they do not recognise.\n\nThe failure it prevents is common and avoidable. A parser configured to reject unknown properties turns every additive change upstream into a breaking one, which means a provider doing nothing wrong takes your integration down. The same happens with values rather than fields: code that switches on a status and throws on anything unexpected will fail the first time the provider introduces a new status, and new statuses are the most ordinary kind of product change there is.\n\nWhat tolerance actually means in practice is narrower than it sounds. Read the fields you use and let the rest pass. Treat enumerated values as open — handle an unrecognised one by holding the record for review rather than crashing or, worse, silently mapping it to a default that is wrong. Do not depend on the order of keys or of array members unless the contract states it. Do not treat the absence of an optional field as meaningful. Validate what you consume, not the whole payload.\n\nTolerance has a cost that is worth naming: a reader that ignores everything unfamiliar will also ignore the change you needed to know about. The pairing that resolves this is to be tolerant at runtime and loud in the logs — record unknown fields and unrecognised values so the integration keeps running and a human still learns that the other side moved. That log line is usually how a team discovers a provider shipped something long before any notice reaches them.","A tolerant reader consumes only the fields it needs and ignores the rest, so an upstream addition is not a breaking change for your integration.",null,[11,14,17,20,23],{"slug":12,"name":13},"api-versioning","API Versioning",{"slug":15,"name":16},"contract-testing","Contract Testing",{"slug":18,"name":19},"openapi-specification","OpenAPI Specification",{"slug":21,"name":22},"schema-registry","Schema Registry",{"slug":24,"name":25},"webhook","Webhook",[27,31,34,38,41,44,47,50,53,56,59,62],{"slug":28,"category":5,"name":29,"updated_at":30},"api-deprecation","API Deprecation","2026-09-08T21:32:37+00:00",{"slug":32,"category":5,"name":33,"updated_at":30},"app-review","App Review",{"slug":35,"category":5,"name":36,"updated_at":37},"backend-for-frontend","Backend for Frontend (BFF)","2026-09-08T21:32:36+00:00",{"slug":39,"category":5,"name":40,"updated_at":30},"bulk-api","Bulk API",{"slug":42,"category":5,"name":43,"updated_at":37},"concurrency-limit","Concurrency Limit",{"slug":45,"category":5,"name":46,"updated_at":30},"connector-versioning","Connector Versioning",{"slug":48,"category":5,"name":49,"updated_at":30},"delete-propagation","Delete Propagation",{"slug":51,"category":5,"name":52,"updated_at":30},"effective-permissions","Effective Permissions",{"slug":54,"category":5,"name":55,"updated_at":37},"event-ordering","Event Ordering",{"slug":57,"category":5,"name":58,"updated_at":37},"field-mapping","Field Mapping",{"slug":60,"category":5,"name":61,"updated_at":37},"function-schema","Function Schema",{"slug":63,"category":5,"name":64,"updated_at":37},"grpc","gRPC"]