标签：#h0hackathon

At first, approvals sound simple. Show a button. Let someone click approve. Continue the workflow. But real approvals are much harder than that. Nod has to answer important questions: Who requested this approval? Who approved or rejected it? Was the person allowed to decide? Did the approval expire? Was the callback delivered? Can we prove what happened later? That is why Nod stores approvals as real state, not temporary UI. Each approval has a status: pending approved rejected expired canceled Only one final decision can win. If two people click at the same time, Nod must safely accept the first valid decision and reject stale attempts. Slack also needs careful handling. Nod verifies Slack signatures, checks the approval and channel, and stores an actor snapshot for the audit log. After a decision, Slack messages can be updated so old buttons are no longer useful. Webhooks also need trust. Nod signs every callback so customer apps can verify it before continuing. const event = nod . webhooks . verify ({ rawBody , headers : request . headers , secret : process . env . NOD_WEBHOOK_SECRET ! , }); We learned that approvals are not just a product feature. They are a security system. A good approval layer needs: Authorization Idempotency Expiration Webhook signing Retry logic Audit logs That is what Nod is built around.

Nod is an approval API for AI agents, scripts, and workflows. The idea is simple: Your app wants to do something risky. Nod asks a human for approval. The human approves in Slack or web. Nod sends a signed callback. Your app continues safely. We built the web app on Vercel . The dashboard lets teams manage: Workspaces Members and roles Approval policies Slack channels API keys Callback endpoints Approval history For the database, we used Amazon Aurora PostgreSQL . Nod needs a strong relational database because approval data must be correct. An approval is not just a UI card. It has a lifecycle. pending -> approved pending -> rejected pending -> expired pending -> canceled Aurora stores the source of truth: Approval requests Human decisions Policy versions Webhook events Delivery attempts Audit logs The backend runs on AWS with Lambda workers. One worker sends Slack notifications. Another sends signed callbacks. Another expires old approvals. A typical flow looks like this: App or agent -> Nod API -> Aurora PostgreSQL -> Slack or web approval -> Signed callback -> App continues Vercel helped us move fast on the user experience. Aurora gave us the reliable data layer needed for real approvals. Together, they helped us build Nod as infrastructure, not just a demo.