Just send any in-app event to a single endpoint, and it shows up in the Dev Dashboard Logs alongside Webhooks, Function runs, and API calls. You can also optionally tie it into "pay for what you use" billing.
Webhooks, Function runs, API calls — you could only see the "called / received" that's visible from Shopify's side.
Just send facts from inside your app — like "feature X was used" or "workflow Y completed" — to a single endpoint, and they line up in the Dev Dashboard.
Decide on the event_handle and attributes you want to track (e.g. bulk_edit_completed).
Send to a single endpoint. It automatically flows into the Dev Dashboard Logs.
View it as a chronological log alongside Webhook / Function / API calls.
// POST {App Events API endpoint} { "event_handle": "bulk_edit_completed", "attributes": { // 追跡したい付帯情報を任意に詰める } }
Rather than preparing a different URL for each event type,use a single API endpoint and distinguish them by event_handleapproach. The sending logic takes very little to implement.
After receipt, it's shown alongside Webhooks / Function executions / API calls on the same screen. Because it unifies your observation point, when an incident occurs you can quickly tell whether it's "on Shopify's side or the app's side."
sync_failedapi_timeoutrate_limit_hit . If you make a practice of sending these, you can track the "when / what / how much" of anomalies in the Dev Dashboard without building your own APM.
When you link an event_handle to a meter in the Partner Dashboard,a single send produces both the log and the billing at once. There's no need to build a second implementation just for billing.
When you later turn them into meters / aggregate reports / set alert conditions, inconsistent handle names fragment your analysis. Verb_pastTense (order_processedlabel_printed) and the like— lock in a naming convention from the start. Note that the per-handle quantities, limits, and schema specifications are not covered in this article.