Step 1
Open Apps Script
In your Google Sheet, go to Extensions > Apps Script. Delete any existing code and paste the function below.
Step 2
Add the Custom Function
JavaScript Add the Custom Function
function TICKATLAS(symbol, indicator, timeframe) {
var API_KEY = PropertiesService.getScriptProperties().getProperty("CLAW_API_KEY");
var url = "https://tickatlas.com/v1/indicator"
+ "?symbol=" + symbol
+ "&indicator=" + indicator
+ "&timeframe=" + timeframe;
var options = {
"method": "get",
"headers": { "X-API-Key": API_KEY },
"muteHttpExceptions": true
};
var response = UrlFetchApp.fetch(url, options);
var data = JSON.parse(response.getContentText());
return data.data.value;
}
// Usage in cell: =TICKATLAS("EURUSD", "RSI_14", "H1")Step 3
Store Your API Key
In the Apps Script editor, go to Project Settings > Script Properties and add a property named CLAW_API_KEY with your API key as the value.
Reference
Step 4: Use in Cells
| Cell Formula | Result |
|---|---|
| =TICKATLAS("EURUSD","RSI_14","H1") | 58.43 |
| =TICKATLAS("XAUUSD","ATR_14","D1") | 28.50 |
| =TICKATLAS("GBPUSD","MACD_main","H4") | 0.00123 |
Production checklist
Tips for a Reliable Sheet
1
Custom functions cache by their arguments, so Sheets may not re-run on every edit. Add a time-driven trigger or a hidden timestamp argument when you need values to refresh on a schedule rather than only on recalculation.
2
Mind your rate limit: a sheet with a hundred TICKATLAS() calls fires a hundred requests on every full recalculation. Pull a batch with /v1/multi into a single cell and reference it from the others to stay well within your plan.
3
Handle errors gracefully — check that data.value exists before returning it, so a failed call surfaces a clear message in the cell instead of a cryptic #ERROR! that is hard to debug.
4
Keep your key in Script Properties, never in a cell. Anyone with view access to the spreadsheet can read cell contents, but script properties stay private to the project.
Before you go live
Production hardening
The code above is the happy path. These are the concerns that decide whether it survives contact with a real deployment.
1
Keep the key server-side. The API key authenticates with the X-API-Key header and must never reach a browser bundle. Proxy it, or use a public widget key, which is domain-scoped and revocable. Authentication
2
Handle 429 before you need to. Rate limits are per key and per minute. Back off on 429 rather than retrying immediately, and read the X-RateLimit-* headers on every response. Rate limits
3
Branch on the error code, not the message. Errors carry a stable machine-readable code; the human-readable text can change. Codes were unified in v3.15. Error handling
4
Expect gaps, and do not invent values. Markets close, feeds stall, and a retention window can reject a request outright. Surface an explicit unavailable state rather than substituting a zero or the last known price. Troubleshooting
5
Cache what you poll. Responses are already cached briefly upstream, so polling faster than the data changes spends credits without improving freshness. Cache on your side and poll on the cadence your timeframe actually updates. Pricing and credits
6
Watch retention per timeframe. History depth is set per timeframe, never per plan, so a request that works on D1 can fall outside the window on M1. Check the published windows before backfilling. Timeframes
7
Rotate keys and scope them. Issue a separate key per deployment so one can be revoked without taking the others down, and rotate on a schedule rather than after an incident. Authentication
8
Log the request, not the key. Record endpoint, parameters, status and latency so a failure is reproducible. Never log the key itself, and scrub it from error reports.
Reference map
Related
Everything this guide touches, linked directly — so it never dead-ends.