$ Credential Flow · Architecture

On its first Salesforce call since starting, the API requests an access token from Salesforce’s OAuth token endpoint using the configured Consumer Key and Secret, then caches it in memory. Every subsequent call reuses that cached token — it is not refetched on every request — until it’s expired or about to expire, at which point the API requests a fresh one before making the call. This is the actual protocol mechanic this case study exists to demonstrate: the token request, its expiry, and when to refetch, not that a Python package can be installed.

Both write endpoints apply the same layered protections used elsewhere on this site: a honeypot field, a minimum-fill-time check, per-IP rate limiting, and a profanity blocklist on the Applicant and Account name fields. Status is restricted to the settable values (Draft, Submitted, Under Review, Approved, Denied) on both create and update — Archived is reachable only by editing Salesforce directly, never through either endpoint.

The delete endpoint checks a record’s current Status server-side and refuses to delete it if that Status is Archived — regardless of what any caller sends, and regardless of whether the request originates from this site’s own UI or a direct API call. Archived records are the original seed data; this protection keeps them permanently intact so the live demo always has a stable baseline to show, no matter what a visitor does through the create/update/delete actions.