Typed provider
Supported integrations use validated provider codes and account identifiers.
Pixels and integrations
Connect attribution tools without pasting executable tags.
Instead of storing arbitrary script snippets, Gods.ly models a supported provider and identifier. This creates a smaller security boundary and a clearer way to disable or review a connection.
Manage integrationsNo script injection
Configuration is rendered by trusted platform code rather than customer-supplied executable HTML.
Visible state
Active and disabled connections remain searchable and auditable.
Configuration should describe intent
A pixel record says which provider should receive a conversion signal and which public identifier applies. It does not store an opaque script with unrestricted browser behavior.
Provider-specific validation catches malformed identifiers before the integration is attached to a campaign.
Consent remains separate from installation
Having a configured pixel does not prove a visitor granted consent. Public renderers must evaluate the applicable consent category and region before loading a provider.
Transactional and security events never become marketing audiences by accident.
See when a provider has a problem
Connection status, delivery results, and limited automatic retries make outages visible without blocking link redirects. Production secrets are stored outside ordinary application settings.
Older integrations stay disabled until their credentials are replaced and their complete workflow has been tested.
Common questions
What teams ask before they start.
Can I paste arbitrary JavaScript?
No. Gods.ly accepts supported provider identifiers rather than arbitrary scripts.
Does enabling a pixel bypass consent?
No. Provider configuration and visitor consent are separate controls.
Start with a real workflow