24 Replit Agent Prompts for Automations & Integrations (2026)

Build a checkout flow for [my product/app] using the Stripe integration.
Who it's for: customers buying [one-time product, e.g. a $29 course].
Flow: user clicks "Buy" -> redirected to Stripe Checkout -> on success returns to a /success page, on cancel returns to /cancel.
Stack: use the Stripe integration; read STRIPE_SECRET_KEY and STRIPE_PUBLISHABLE_KEY from Secrets — never hardcode keys. Store completed orders (email, amount, product, stripe_session_id, created_at) in the database.
Done looks like: in Stripe TEST mode I can complete a purchase with card 4242 4242 4242 4242, land on /success, and see the order row in the database.
Out of scope for now: subscriptions, refunds, coupons.
Run this in Plan Mode first and show me the plan before building.

Add a Stripe webhook receiver to this app.
What to build: a POST endpoint at /webhooks/stripe that verifies the Stripe signature and handles checkout.session.completed and charge.refunded events.
On checkout.session.completed: mark the matching order as paid and set paid_at. On charge.refunded: mark it refunded.
Stack: read STRIPE_SECRET_KEY and STRIPE_WEBHOOK_SECRET from Secrets; use Stripe's signature verification so unsigned requests are rejected with 400.
Done looks like: in Stripe TEST mode I can trigger a checkout.session.completed event and see the order flip to paid; an event with a bad signature returns 400 and is not processed.
Log each received event type and outcome. Don't change my existing checkout code.

Add recurring subscriptions to this app using the Stripe integration.
Plans: [Basic $9/mo, Pro $29/mo] as Stripe Prices. Flow: logged-in user picks a plan -> Stripe Checkout in subscription mode -> returns active; add a "Manage billing" link that opens the Stripe Customer Portal.
Data: store customer_id, subscription_id, plan, status, current_period_end on the user.
Stack: keys from Secrets (STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET); handle customer.subscription.updated and .deleted webhooks to keep status in sync; gate premium features on status === 'active'.
Done looks like: in TEST mode I can subscribe, see status active, open the portal to cancel, and watch the webhook set status to canceled.
Run in Plan Mode first.

Build an internal tool that generates Stripe Payment Links on demand.
Who it's for: our sales team creating one-off invoices.
Flow: a simple form (product name, amount, currency, optional customer email) -> creates a Stripe Payment Link via the API -> shows the shareable URL and saves it to a table (name, amount, url, created_by, created_at).
Stack: STRIPE_SECRET_KEY from Secrets; protect the tool behind Replit Auth so only our team can use it.
Done looks like: I submit the form in TEST mode and get back a working Stripe-hosted payment URL that I can open and pay with a test card, and the link appears in the history table.
Keep it minimal — no dashboards yet.

Add a Slack notification whenever a new user signs up in this app.
What to build: on successful signup, post a message to our Slack channel with the new user's name, email, and signup time.
Stack: use the Slack integration; read SLACK_BOT_TOKEN from Secrets and post to channel [#signups]. Make the message formatted and readable (bold name, plain email).
Reliability: if Slack fails, log the error and don't block the signup flow.
Done looks like: when I create a test account, a formatted message appears in [#signups] within a few seconds, and a failed Slack call still lets the user sign up.
Don't post duplicate messages if signup is retried.

Build a Slack slash-command bot.
What to build: a /[stats] slash command that, when run in Slack, returns [today's signups, revenue, and active users] from our database as a formatted reply.
Stack: read SLACK_BOT_TOKEN and SLACK_SIGNING_SECRET from Secrets; verify Slack's request signature so only real Slack requests are handled; respond within 3 seconds (use an immediate ack + follow-up message if the query is slow).
Deploy: this needs a public HTTPS endpoint — deploy as an Autoscale deployment and give me the request URL to paste into the Slack app config.
Done looks like: typing /[stats] in Slack returns the correct numbers as a nicely formatted message; a request with an invalid signature is rejected.

Build a Discord bot for our community server.
Features: (1) a !help command listing available commands; (2) a !ticket command that DMs the user and creates a support ticket row in the database (user_id, message, status=open, created_at); (3) auto-welcome new members with a message in [#welcome].
Stack: read DISCORD_BOT_TOKEN from Secrets; use the Discord integration/gateway. Keep the bot running with a Reserved VM deployment so it stays connected.
Done looks like: in my test server, !help lists commands, !ticket creates a DB row and DMs me a confirmation, and a new member gets a welcome message.
Out of scope: moderation and roles for now.

Add Twilio SMS alerts to this app.
What to build: when [an order is placed / a form is submitted], send an SMS to our ops number with the key details.
Stack: use the Twilio integration; read TWILIO_ACCOUNT_SID, TWILIO_AUTH_TOKEN, and TWILIO_FROM_NUMBER from Secrets. Send to the number in [OPS_PHONE] (also a Secret).
Reliability: log every send (to, body, status, twilio_sid); retry once on failure; never let an SMS failure break the main action.
Done looks like: triggering the event sends a real SMS to my test phone within seconds and writes a log row with the Twilio SID; a bad number is logged as failed without crashing.
Keep messages under 160 characters.

Build an appointment SMS reminder system with Twilio.
Data: appointments (name, phone, appointment_time, reminder_sent).
Job: a script that finds appointments starting in the next [24 hours] with reminder_sent = false, sends each a Twilio SMS reminder, and marks reminder_sent = true.
Stack: Twilio keys from Secrets (TWILIO_ACCOUNT_SID, TWILIO_AUTH_TOKEN, TWILIO_FROM_NUMBER). Set the job up as a Scheduled Deployment that runs [every hour].
Done looks like: I add a test appointment 24h out, the scheduled job runs, I receive one SMS, and reminder_sent flips to true so I don't get a duplicate on the next run.
Idempotency matters — never send the same reminder twice.

Add transactional email to this app using SendGrid.
Emails to send: (1) password reset with a secure token link; (2) order confirmation with the order details.
Stack: use the SendGrid integration; read SENDGRID_API_KEY from Secrets and send from [noreply@mydomain.com] (also a Secret, FROM_EMAIL). Use clean HTML templates with a plain-text fallback.
Reliability: log each email (to, template, status); don't block the request if sending is slow — send async and handle failures gracefully.
Done looks like: requesting a password reset delivers a real email to my test inbox with a working reset link; placing an order delivers a confirmation. Both show up in the email log.
Out of scope: marketing/newsletter email.

Build a 3-email welcome sequence with SendGrid.
Sequence: on signup send email 1 immediately; email 2 after [2 days]; email 3 after [5 days]. Content: [welcome + first step], [feature highlight], [tips + upgrade CTA].
Data: track per-user sequence progress (user_id, step, sent_at) so we never resend a step.
Stack: SENDGRID_API_KEY and FROM_EMAIL from Secrets. Use a Scheduled Deployment that runs [daily] to find users due for the next email and send it. Include an unsubscribe link that stops the sequence.
Done looks like: a test signup gets email 1 now; when I fast-forward the schedule, emails 2 and 3 arrive on cadence and never duplicate; clicking unsubscribe halts further emails.

Add a Google Sheets sync to this app for [orders].
What to build: whenever an [order] is created or updated, upsert a row in a Google Sheet (match on order_id). Columns: Order ID, Customer, Email, Amount, Status, Created At, Updated At.
Stack: use the Google Sheets integration; read the service-account credentials / GOOGLE_SHEETS_KEY and the SHEET_ID from Secrets. Upsert, don't append duplicates.
Reliability: if the Sheets API fails, queue the change and retry; log sync status per row.
Done looks like: creating a test order adds one row to the Sheet; updating it changes that same row in place (no duplicate); I can see the Sheet ID in Secrets, not in code.
Out of scope: reading edits back from the Sheet for now.

Build a public contact form that saves submissions to a Google Sheet.
Flow: a clean, mobile-responsive form (Name, Email, Message) -> on submit, validate inputs, append a row to a Google Sheet, and show a thank-you message.
Stack: use the Google Sheets integration; GOOGLE_SHEETS_KEY and SHEET_ID from Secrets. Add basic spam protection (honeypot field + simple rate limit by IP).
Design: clean and modern, single column, works on mobile.
Deploy: Autoscale deployment so it's publicly reachable.
Done looks like: submitting the form appends a timestamped row to the Sheet and shows the thank-you; the honeypot blocks obvious bots; the Sheet ID lives in Secrets.

Sync this app's [contacts] to Airtable.
What to build: on create/update of a [contact], upsert the matching Airtable record (match on our internal id stored in an Airtable field). Map fields: Name, Email, Company, Status, Last Contacted.
Stack: read AIRTABLE_API_KEY, AIRTABLE_BASE_ID, and AIRTABLE_TABLE from Secrets. Respect Airtable rate limits (5 requests/sec) — throttle and retry on 429.
Done looks like: creating a contact creates one Airtable record; editing it updates the same record; hammering the sync doesn't hit rate-limit errors because requests are throttled.
Log each sync with the Airtable record id and status.

Push new [blog posts / tasks] from this app into a Notion database.
What to build: when a [post] is published, create or update a Notion page in the target database with properties: Title, Status, Author, Published Date, and a URL back to the app.
Stack: read NOTION_API_KEY and NOTION_DATABASE_ID from Secrets; use the Notion integration. Match on a stored Notion page id so updates edit the existing page instead of creating a new one.
Done looks like: publishing a test post creates one Notion page with all properties set; editing and re-publishing updates that same page; the API key is in Secrets only.
Out of scope: two-way sync from Notion back to the app.

Build a webhook receiver that ingests events from [external service, e.g. Typeform / GitHub / a payment provider].
What to build: a POST endpoint at /webhooks/[service] that validates the shared secret / signature, parses the payload, stores the raw event and parsed fields in a webhook_events table, and triggers [the action, e.g. create a task].
Stack: read WEBHOOK_SECRET from Secrets; reject requests with a missing/invalid secret (401). Always respond 200 fast (under 2s) and process heavy work asynchronously so the sender doesn't time out and retry.
Deploy: Autoscale so it's publicly reachable; give me the endpoint URL to register with [service].
Done looks like: sending a sample payload with the right secret stores the event and triggers the action; a wrong secret returns 401; the endpoint always answers within 2 seconds.

Add outbound webhooks so other systems can subscribe to events from this app.
What to build: an admin UI to register webhook endpoints (url, event types, secret). When [an order is created / a status changes], POST the event JSON to every subscribed endpoint, signing the body with the endpoint's secret (HMAC in an X-Signature header).
Reliability: retry failed deliveries with exponential backoff up to [5] times; log each attempt (endpoint, event, status_code, attempt). Disable an endpoint after [10] consecutive failures.
Stack: protect the admin UI with Replit Auth; store secrets encrypted.
Done looks like: I register a test endpoint (use a request-bin URL), trigger the event, and see a signed POST arrive; a failing endpoint retries with backoff and is disabled after repeated failures.

Add an OpenAI-powered classifier to our support inbox.
What to build: when a support ticket arrives, call the OpenAI API to (1) categorize it [Billing / Bug / Feature Request / Other], (2) rate urgency [Low/Med/High], and (3) draft a suggested reply. Store category, urgency, and draft on the ticket; a human approves before anything is sent.
Stack: read OPENAI_API_KEY from Secrets; use a current chat model with a low temperature for consistent labels. Cap tokens and handle API errors/timeouts gracefully (fall back to "Uncategorized").
Done looks like: creating a test ticket fills in category, urgency, and a draft reply within a few seconds; an API failure leaves the ticket as "Uncategorized" instead of crashing.
Out of scope: auto-sending replies without human approval.

Build an API endpoint that summarizes long text with OpenAI.
What to build: a POST /summarize endpoint taking { text, length } and returning a summary plus 3-5 bullet key points. Validate that text isn't empty and isn't over [50k] characters.
Stack: OPENAI_API_KEY from Secrets; protect the endpoint with an API key of our own (read APP_API_KEY from Secrets, require it in an Authorization header). Rate-limit per caller. Cache identical requests for [1 hour] to save tokens.
Done looks like: POSTing sample text with the right Authorization header returns a JSON summary + bullets; a missing/invalid app key returns 401; a repeat request within the hour is served from cache (visible in logs).
Return clear JSON errors, not stack traces.

Build a daily report bot that posts a summary to Slack.
Job: each morning, query the database for yesterday's [new signups, orders, revenue, and top referrer], format them into a readable summary, and post to Slack channel [#daily-report].
Stack: read SLACK_BOT_TOKEN from Secrets. Set this up as a Scheduled Deployment that runs [every day at 8am my timezone].
Done looks like: I can run the deployment manually once and see a correctly formatted report in [#daily-report] with yesterday's real numbers; on a day with no activity it posts "No activity yesterday" instead of an empty or broken message.
Keep the query efficient and log each run's status.

Build an RSS-to-email digest.
Job: each morning, fetch these RSS feeds [list feed URLs], collect items published in the last 24 hours, dedupe by link, group by source, and email me a clean digest with titles + links via SendGrid.
Data: track already-sent item links so nothing repeats across days.
Stack: SENDGRID_API_KEY and FROM_EMAIL / TO_EMAIL from Secrets. Run as a Scheduled Deployment [daily at 7am my timezone].
Done looks like: running the job delivers one digest email to my inbox with only the last 24h of items, grouped by source, no duplicates; on a slow day with nothing new it emails a one-line "nothing new today" instead of an empty message.
Handle a feed being down without failing the whole run.

Build a scheduled database backup job.
Job: each night, export the database (or the key tables [list]) to a timestamped file and upload it to [Google Drive / S3 / an object store]. Keep the last [14] backups and delete older ones.
Stack: read the storage credentials from Secrets ([e.g. AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, BUCKET] or the Drive integration). Run as a Scheduled Deployment [nightly at 2am].
Done looks like: running the job produces a timestamped backup file in the destination and, after [15] runs, only the most recent 14 remain; a failed upload is logged and (optionally) alerts me via [Slack/email].
Never store credentials in code.

Build a scheduled sync between [external API, e.g. our CRM] and this app's database.
Job: every [hour], pull records changed since the last successful sync from [external API] and upsert them into our [contacts] table (match on external_id). Store a last_synced_at watermark so each run only fetches deltas.
Stack: read the external API key from Secrets ([CRM_API_KEY]); respect its rate limits with throttling + retry on 429/5xx. Run as a Scheduled Deployment [hourly].
Done looks like: a record I change in [external API] appears/updates in our DB within an hour with no duplicates; the watermark advances only on a fully successful run so a mid-run failure re-fetches safely next time.
Log records processed and any errors per run.

Build a monitor that watches [these URLs / product prices] and alerts on change.
Job: every [15 minutes], check each URL in [list]. For uptime: flag any non-200 or slow (over [3s]) response. For price: scrape the price and compare to the last stored value.
Alert: on a status change (up->down, down->up) or a price change, send a Twilio SMS and/or Slack message; don't re-alert while the state is unchanged.
Stack: read TWILIO_* / SLACK_BOT_TOKEN from Secrets. Store each check (url, status, price, checked_at). Run as a Scheduled Deployment [every 15 minutes].
Done looks like: taking a test URL down triggers exactly one "down" alert (not one every run) and one "recovered" alert when it's back; a price drop sends one alert and updates the stored price.