POSTGRESQL · API INTEGRATION · DATA QUALITY
I built a small Chord assistant for a friend's thrift business, then checked its purchase requests against the database. The useful part was making sure the record, the API response and the customer message agreed.
01 / BUSINESS PROBLEM
The owner described spending time answering questions about measurements, prices and availability across Instagram and WhatsApp. Tracking what had been discussed, paid for or left pending meant reviewing chat histories and separate records.
I kept the build to one workflow: identify an item, retrieve its details, ask for confirmation and save an unpaid purchase request. Only payment secures an item, so recording interest must never imply a reservation or a completed sale.
This is a demo based on the owner's account, not a production rollout. I did not establish a dated incident, a handling-time baseline or measured sales impact.
02 / DATA MODEL
One row per fictional item code. The primary key identifies the item, while price, currency, size, measurements and availability describe the catalogue record.
Prices are integer kobo in NGN. Measurements keep their units and basis. Missing measurements are not zero, and unknown availability is not available.
PRIMARY KEY (item_id)One unpaid pending request per customer and item. The row records its own ID, catalogue price and currency, pending status, unverified payment status and creation time. It references the product.
The unique customer/item constraint prevents a retry from becoming a second request. This demo has no cancellation or reorder lifecycle.
UNIQUE (customer_ref, item_id)A pending request measures purchase intent. Its amount is not paid sales or revenue. Multiple customers can express interest in the same item because pending requests do not reserve stock.
03 / INTEGRATION
01 / CONVERSATION
Answer from connected data, ask for confirmation and distinguish pending intent from payment.
02 / API
Authenticate requests and expose product lookup, request creation and retrieval.
03 / DATABASE
Check catalogue price and stock, apply database constraints and store the request.
04 / VERIFICATION
Use DBeaver or Supabase SQL Editor to match the stored row to the conversation.
A transaction lock serializes creates for the same customer/item, with the unique constraint as the final guard. A row lock keeps the checked product stable until the transaction ends.
If the write result is uncertain, check the same pair before retrying. A timeout does not prove the write failed.
The Worker uses Supabase's HTTP API, with no application PostgreSQL pool or growing user cache. I added byte limits while reading input and database responses, cancelled unused response bodies and cleared the upstream timer.
These changes were deployed. I did not run a sustained memory profile, load test or connection-pool saturation test.
04 / EVIDENCE
During testing, the agent supplied a saved-order ID that did not exist in PostgreSQL. I checked by ID and customer/item, confirmed the absence in a separate SQL query, then used API logs and a fresh lookup to investigate. The original write trace was missing, so I could not establish its exact failure.
I required a successful create response followed by retrieval of the same ID. Retrying the original request produced POST and GET logs and a matching row at NGN 13,200, pending with payment unverified. Later saves were also checked against SQL. Recovery worked, but the agent's explanation of its own actions was still inconsistent in a later run.
The 20 local tests comprise nine checks for the earlier SQLite service and eleven for the PostgreSQL HTTP adapter using simulated responses. They are not 20 live Chord tests. Hosted SQL checks and specific simulator runs are listed separately in the repository.
05 / LIMITS AND NEXT STEPS
The agent sometimes asks for a second confirmation. A simulator no-answer incident and inconsistent tool-use narration remain documented. The working examples demonstrate specific saves and retrievals, not production reliability.
Real use needs maintained inventory, authenticated customer identity, staff permissions, verified payments and tested human escalation. The current build does not take payments, reserve stock, update Instagram, arrange dispatch or send reminders.
I would start with a supervised pilot and compare owner handling time and order errors before and during use. No time-saving or conversion claim has been measured.
AI assistance: ChatGPT/Codex helped with the skill, code, tests and troubleshooting. I configured and deployed the integration, ran the conversations and SQL checks, and recorded the demo.
06 / REVIEW THE WORK
The repository includes the skill, API code, schema, SQL checks, test fixtures and setup instructions. The WhatsApp simulator requires Chord exercise access; the recording provides a walkthrough without that access.