daymaker.com

Daymaker sends custom cakes: an edible photo/design print on top, baked by a vetted local bakery and hand-delivered to the recipient's door. People use it for congratulations, birthdays, launches, and unforgettable business outreach ("coldcaking"). The full gifting loop: 1. check_delivery_coverage — is the recipient's address deliverable, and what do sizes cost there? (no auth needed) 2. get_cake_catalog — sizes, shapes, from-prices. (no auth needed) 3. start_gift — creates a draft gift; returns gift_id + gift_token. The gift_token is a SECRET credential: keep it for the session, pass it to every later tool, and never reveal it to anyone but the gift's owner. If the sender has a Daymaker account, pass their account_token here (they get it from the Connect AI page at daymaker.com/customer, or it can be pinned onto the connection as ?token= on the server URL): the gift then opens ON their account and appears in their campaign list with everything they ordered on the website. Without it the gift is a standalone order that only its own tracking link can see — worth telling the sender, because it surprises people. Never invent an account_token. 4. find_recipient_address — optional: turn a company website into a verified mailing address, plus whatever switchboard number and general inbox that company publishes. Those two are the front desk, not the recipient: pass them along (a courier who can call gets the cake handed over), but say what they are, and take the sender's own details over them every time. 4b. find_recipient_logo — optional: turn that same website into the logo they already publish, plus their brand colors. Worth calling before you design: a cake carrying the recipient's real mark and colors lands very differently from a generic one. We never invent a logo, and we tell you when one is too low-resolution to print. 5. add_recipient — who gets the cake and where. Tells you immediately if it's deliverable. Got it wrong, or the sender produced a phone number afterwards? update_recipient fixes the row in place (re-routing if the address moved) and remove_recipient takes it off. Never re-add to correct something — that orders a second cake. 6. set_gift_design — the artwork: author your own SVG design (we rasterize it print-ready), or pass an image URL, base64 image bytes, or a short message we typeset. get_cake_catalog documents the fonts and print-safe layout rules; the tool returns print-fit warnings so you can iterate. An SVG you author may NOT reference external URLs — to put the recipient's logo inside your design, use the logo_data_uri that find_recipient_logo returns. 7. set_gift_card — the 4×6 card packed in the box: a note we typeset, or your own artwork. 8. create_checkout — locks the price and returns a Stripe Checkout URL. Hand that URL to the human; they pay in the browser. You never collect payment details. 9. get_gift_status — payment/production/delivery tracking, with photos once delivered. list_gifts turns "the cakes I sent last week" into the gift_id every tool here needs — with an account token it lists everything that account has ordered, website orders included. AFTER PAYMENT the artwork is frozen: the file the bakery prints from is a snapshot taken at checkout, so new art is a REQUEST a bakery answers, never an edit. list_design_changes shows which cakes can still change and where every ask so far stands; request_design_change proposes new artwork — one call can carry a DIFFERENT file for every cake on the order, which is the point of it, so never send them one at a time; withdraw_design_change takes back an unanswered ask (only one can be open per bakery, so this is how you make room for another). Until a bakery accepts, the ORIGINAL design is still what gets printed — say that plainly rather than telling the sender their new artwork is confirmed, and remember a bakery can accept a change over cakes that are already baked, in which case the answer says how many actually moved. Two things are optional but almost always wanted, so ASK about them instead of skipping them silently: the card in the box (set_gift_card — the cake print is a bad place for a long message; the card is where words belong) and the recipient's phone number (add_recipient's phone — the bakery calls it when nobody answers the door). The phone can't be changed once the gift is paid; the card can, but only as a design change the bakery has to accept. Pricing: from $80–$100 for a standard cake (exact price depends on size and delivery area; check_delivery_coverage gives real numbers). Drafts are free — nothing is charged or baked until the checkout link is paid. AUTOMATIONS (standing rules, not one-off gifts): create_automation sets up "every time X happens, send a cake" — customer churned, tenure milestone, new employee started. It returns an automation_token (SECRET owner credential; also opens the human dashboard) and a webhook ingress URL the customer's systems can POST events to. fire_automation triggers a send directly from the agent with a fire-once guarantee (same recipient + event never gets two cakes). Automations are born PAUSED with 'approve' payment (the owner emails-confirms every charge); update_automation activates. list_automations / get_automation_runs inspect state. RESEARCHED GIFTS (not cakes): Daymaker is also a gift advisor. It researches a person from what they publish, picks a gift they would actually love, and buys and ships it once a human pays. These tools need a Daymaker ACCOUNT on the connection (the ?token= tail, or account_token on the call) because research is metered to that account's allowance; they refuse guests and never run anonymously. The loop: 1. research_prospect — a name (or LinkedIn URL) in; a job out. Daymaker research reads their talks, posts and side projects and the gift engine shops the dossier. Or suggest_gift — for someone the sender already knows: their interests in the sender's own words, no research, cheaper and faster. Both return a prospect_id at once and take minutes, so say so, and pass external_id (your own id for the person) so a repeat call resumes instead of paying twice. 2. get_gift_recommendation — poll every 20 to 30 seconds until status is "gifted": gift.idea, gift.note (the sentence the sender can send), gift.product_url, gift.price and gift.verified. "failed" is final for that job. 3. buy_gift — quotes the picks for one or more people and returns a Stripe Checkout URL the human pays; Daymaker buys and ships. Ask the sender how it gets there first ("link": the recipient is emailed the gift's name and types their own address, the default and the only option when you hold no address; "direct": ship to addresses the sender gives you) and whether a card rides along. Owner and admin tokens only. 4. get_gift_order_status — payment and fulfilment per recipient; also confirms a payment the moment it lands. A researched gift and a cake are different products with different money paths: a cake is an order this server bakes (create_checkout); a gift is a purchase Daymaker fulfils (buy_gift). Both end in a Stripe link a human pays. Nothing here is charged or bought until that link is paid. WATCH LISTS (people who matter, watched for a reason to send): watch_people puts people on a list; Daymaker then reads what they publish (LinkedIn, X, GitHub, their site, Devpost, their company's news, a weekly LinkedIn headline check; Instagram only teaches taste) and, when a post is worth a gift, picks one. list_watch_suggestions shows the open cards with the post, the reason and the gift; decide_watch_suggestion approves (the pick lands on their row in People, buy it with buy_gift or from the lab) or skips. Each check of one person costs credits (list_watchlists says how many); nothing is bought from these tools. They need an account token.