Recipes
End-to-end automation walkthroughs. Wire Graniite into the systems that already hold your content.
Each recipe starts with a real-world trigger source and ends with content queryable in your Graniite library. Pick the one closest to your use case. The patterns generalize.
Available recipes
Twilio call recording to Graniite
Webhook fires on call end. AssemblyAI transcribes. You can search the conversation 30 seconds later. Real-time.
Google Drive sync to Graniite
A new file lands in a watched Drive folder. The ingest pipeline routes by file type. Ready to query within minutes. Event-driven.
Bulk import from CSV
Script-driven import of a list of URLs and pasted text. Useful for migration from Readwise, Pocket, or Notion. One-shot or scheduled.
How to think about recipes
| Shape | Trigger | When to use |
|---|---|---|
| Webhook-driven | An external system fires when an event happens | Real-time: voice calls, customer events, fresh content |
| Event-driven | A trigger system (n8n, Zapier) watches a source and reacts | Near-real-time: new files in Drive, new emails, RSS items |
| Batch or scheduled | A script or cron job runs periodically | One-shot migrations, daily catch-up, defensive de-dupe |
The Twilio recipe is webhook-driven. The Drive recipe is event-driven. The bulk-import recipe is batch. Together they cover the three shapes most automations fall into.
What each recipe sets up
Before the recipe-specific work, all three need:
- A Graniite account signed in at graniite.co.
- A token minted at
/settings/integrations. See Authentication for what to pick. For most automation use cases, choose read and write, whole library, with a 90-day expiry. - The bearer token saved in your trigger system's secrets (n8n credentials, GitHub Actions secrets, and so on). Never commit it to a repo.
The recipes use n8n as the orchestrator in examples because it is the most common no-code trigger system. The patterns work identically in Zapier, Make, Pipedream, or a hand-rolled script.
A note on idempotency
Webhook-driven and event-driven pipelines occasionally fire twice for the same source (retries, network blips). Graniite's URL ingest deduplicates by content URL for YouTube (one canonical row across all users). For other URL types, the duplicate creates a second user_item row pointing at the same content row.
If duplicate-firing would be a problem, gate the trigger on a Boolean property in your upstream system ("processed: true") or maintain a small "seen this URL today" Redis check before the ingest call. Each recipe covers its own idempotency posture.