An integration is an outside product that Rhythm can work with, such as a payment processor, email marketing platform, learning management system, or webinar tool. A connection is the setup record your Rhythm account uses for that integration. It stores the credentials or approval, points Rhythm to the right outside account or client, and holds the rules Rhythm follows when it uses that product.
You manage connections in the Console under System & Security › Integrations. Most integrations have their own settings page there, named for the product, such as Canvas LMS, Mailchimp, or Authorize.Net. That page either lists the connections you already have or acts as the single settings record when your account can have only one connection to that product.
Two Ways to Connect
Depending on the integration, you connect it in one of two ways:
- Enter credentials Rhythm stores. You enter the key, token, or account identifier the outside product issued to you, and Rhythm saves it on the connection record. Most learning, community, and some marketing platforms work this way. The replacement field is named for the value that connector uses: the BluePay connection calls it Secret Key, while the Informz connection calls it Encryption Key. When the outside product gives you a new value, update that field on the existing connection instead of recreating the connection.
- Approve Rhythm at the outside platform. Rhythm sends you to the other product’s sign-in and approval screen. When you approve access, that product gives Rhythm a token, and Rhythm saves it as the connection. Mailchimp and Campaign Monitor connections work this way.
A few integrations, such as OpenWater, do not have a settings page. You record, read, and remove those connections entirely through the API. See OpenWater Accounts and Bulk Connection Changes Through the API and Maintain Connections Through the API.
After you save the connection, the Rhythm applications that use it, such as Events, CRM, and Finance & Billing, read it automatically. You do not need to enter the same information again for daily work.
Connecting Through Rhythm's API
Not every outside product has its own settings page in the catalog. If you use a tool without one, such as Jotform, an ecommerce platform, an outside event-registration platform, or a compliance-tracking system, you connect it by building against Rhythm’s open API instead of using a Console page. Start with Rhythm’s API documentation site to find the endpoints you need. That is the starting point for any API-based integration, whether Rhythm engineering needs to get involved or not.
Whether you need help from Rhythm engineering depends on the integration. Many third-party integrations go live without Rhythm engineering work when the outside vendor can build directly against the published API documentation. When a question goes beyond that documentation, such as a custom data flow, unusual volume, or a problem the documentation does not address, contact Rhythm support. Some deeper help may have its own cost because engineering review or hands-on implementation assistance is billable work, not part of standard support.
A few terms come up often when you work with the API directly:
- Payload. The data sent with a request or returned in a response. If Support asks for the payload of a failed call, they mean the exact data your integration sent or received, so they can see what went wrong.
- Contact identifiers can appear in more than one format. Some contact records use a numeric identifier, while others use an alphanumeric one. Build your integration to accept either format, because treating an alphanumeric identifier as invalid will make otherwise-valid records fail.
- A field you need may not exist as a single value. Some data an integration needs is not stored in one Rhythm field. It may come from combining values across more than one API resource, such as one value from the Contacts endpoints and another from the Memberships endpoints. Check both before you decide a field is missing.
Warning
If your integration sends organization profile images through the API, use the exact public image URL format Rhythm expects. A URL with an extra path segment or the wrong suffix can save without an error, but the image will not display. If images stop appearing after a payload change, check the URL format first.
If you already have a saved query set up in Rhythm, an integration does not need to duplicate that logic. Look up the saved query’s ID in the Console, then call the query execution endpoints to start it and retrieve results instead of rebuilding the same query outside Rhythm.
Tip
If your integration calls the API at a high volume, build retry discipline in from the start. Back off with jitter between retries, honor a Retry-After value when Rhythm sends one, avoid large bursts of requests, queue work at a controlled rate, cap how many times you retry a single request, and log the request and response for anything that fails. This keeps a busy integration from behaving like an outage on either side.
Whether your integration needs its IP address allowed ahead of time depends on which integration you are using. Check the setup guidance for that specific connection instead of assuming every API integration requires it. If an existing vendor integration changes to a new host or domain, tell Rhythm. The new address may need to be allowed before requests from it are accepted, and this kind of change usually needs Rhythm engineering rather than a same-day support fix.
Setting Up Auth0-Based Sign-In and API Access
Many integrations authenticate through Auth0, the identity service behind Rhythm’s own sign-in. You do not get direct access to that Auth0 configuration yourself. Rhythm staff create the Auth0 application for you, then give you the client secret so you can finish configuration on your side. If you need to change that application later, such as adding a callback URL, support can identify the right application when you provide its Client ID.
| What the integration needs | Typical values |
|---|---|
| A machine-to-machine integration (server-to-server, no signed-in user) | Your Rhythm environment’s Auth0 domain, a client ID, and a client secret |
| An SSO integration for an actively signed-in user | The same domain, plus allowed callback and logout URLs for each environment that will use it |
| An analytics or reporting integration that reads your data on a schedule | An account identifier for your Rhythm environment, an Auth0 base URL, a client ID, and a client secret, using the machine-to-machine pattern |
| An embedded, vendor-hosted feature (for example, an embed-style dashboard) | An active account with that vendor, plus the vendor’s own embed secret, API key, and host value, before Rhythm can create the environment parameters needed for first-use setup and end-to-end testing |
| An event-management integration that prints badges or checks people in | Several separate values from different places: an authentication endpoint, an account identifier, a client ID from the Auth0 application, a client secret delivered separately as a one-time secret, and an event ID from the Console |
The Auth0 application type depends on the integration pattern, not on your preference. A regular web application supports interactive sign-in for an actual signed-in user. A machine-to-machine application supports a server-to-server process with no user present. Some integrations reuse an application you already have. A few need no customer-side Auth0 application because they use writebacks or API access that does not touch identity. If you are not sure which type an integration needs, ask Rhythm support before you build against the wrong one.
A website or CMS with an actively signed-in user should usually call the API with that user’s own sign-in token, not a machine-to-machine token. Machine-to-machine tokens are for automated processes with no signed-in user, or for retrieving public data with no user context. A website that supports member sign-in and also pulls public data may need a web SSO application for the first case and a machine-to-machine application for the second. A third-party mobile app that only needs API access for event data, and is not asking members to sign in with their Rhythm credentials, does not need an Auth0 application or SSO settings such as callback or logout URLs. You can give that vendor a token and the API documentation instead. If the same app later needs attendees to sign in with their Rhythm credentials, that is a separate requirement. API credentials for data access do not also enable attendee sign-in, so you need to add a distinct Web SSO setup with its own redirect and logout URLs from the vendor.
Warning
API requests need a bearer access token, not an ID token, even though some setup documentation describes the ID token as the bearer token. If you get unexpected authorization failures, confirm you are sending the access token from your Auth0 flow.
A machine-to-machine token that calls the API this way is different from a signed-in user’s token. SSO tokens are limited in which endpoints they can call, so integrations that do not need a signed-in user usually work better with a machine-to-machine token. For a browserless process, such as a plugin execution path or scheduled import, use the client-credentials flow instead of the authorization-code flow. Use the audience value documented for client-credentials authentication, not the audience used for browser-based login. Mixing those up is a common cause of a 403 “not enabled” error at the token endpoint. The access token, API audience, client ID, client secret, and your account’s Auth0 domain each serve a different role, and none can replace another.
Machine-to-machine tokens last 24 hours, and issuing new ones is capped at roughly 1,000 tokens a month for that flow. Other authorization flows are not subject to this cap. Cache the token you receive and reuse it until it expires instead of requesting a new one on every call. A broken caching implementation can quickly exhaust that monthly allowance. Requesting a fresh token on every end-user sign-in, caching inconsistently across code paths, or silently failing to write to the token cache, such as after a file-permission change makes the cache readable but not writable, can all push usage toward the cap within days. If your integration suddenly starts hitting the monthly limit, check every place in your code that requests a token, confirm the cache is actually being written, and test with a small batch before turning the schedule back on.
Two Rhythm credentials are easy to confuse. An API key sent in an x-api-key header is not the same as the client secret from an Auth0 application’s settings, even when documentation for one integration mentions both. Check which one the setup guide asks for. Some integrations need both an API key and the associated Auth0 application’s client ID, not just one or the other. Before you rotate a client secret, identify every integration or system actively using it. Rhythm does not maintain a ready inventory of which integrations use a given client secret, so check with each vendor or team you have connected. The same is true in the other direction: there is currently no self-service report that shows which integration or application is generating the most authentication traffic. Contact support if you suspect a specific connection is unusually heavy.
OpenID Connect is a supported single sign-on option wherever an Auth0-based integration path is available. If you are evaluating whether a third-party platform is a good candidate for this kind of authentication-only setup, a platform that already offers OpenID Connect and lets you configure SSO on its side is a strong sign that it can work.
Warning
Rhythm’s Auth0 arrangement does not support SAML-based single sign-on. If a platform specifically requires SAML, you can use your own separate Auth0 account instead of Rhythm’s. Your organization would be responsible for that Auth0 account’s cost.
If your account’s Auth0 sign-in domain changes, such as after a rebrand, treat every connected application as needing a matching update. Do not update only Rhythm’s own sign-in. In one such change, a public-facing WordPress plugin and Rhythm were updated to the new domain quickly, but a separate SSO-connected platform kept failing until that outside provider confirmed it could support the new domain too. Until every connected identity provider confirms it points to the current domain, treat any SSO integration that suddenly stops working as a possible match for that cause.
Completing some Auth0 connections requires access to the Auth0 account itself, separate from your Rhythm permissions. If you lose that access partway through setup, support can send you an invitation to rejoin it. For local development and testing, an Auth0 application’s allowed callback URLs can include localhost addresses on specific ports. Production and development environments generally need their own callback URLs added separately and explicitly. A URL that works for one will not automatically work for the other.
If a partner integration built on Auth0 asks for a userinfo endpoint, use the one your Auth0 application already exposes. Rhythm does not require separate configuration on its side for it.
Tip
Testing in a sandbox does not guarantee identical behavior once you go live. In one payment integration, a sandbox accepted either of two stored credential values, while the live processor accepted only one. The mismatch went undetected for months because sandbox testing kept passing. If a payment integration behaves differently in your live account than it did in your sandbox, do not assume the sandbox result was wrong. Verify the live credentials on their own.
Website, Portal, and Mobile Sign-In Integrations
Adding a normal link from the member portal to an outside website is straightforward, but that link does not sign the member in to the other system. Automatic member authentication on an outside site is a separate integration. The outside system has to integrate with Rhythm’s identity or API approach for that to happen. A portal link alone never creates single sign-on.
When you scope a new single sign-on request, start by confirming the login entry point. Members might start by signing in through Rhythm, or they might sign in directly on the outside website before that system gets involved. A request for members to sign in on a third-party site using the credentials tied to their Rhythm account is different from a request to sign members into Rhythm from a link on that site. The setup differs accordingly.
If your onboarding flow should return new and existing members to the portal, rather than your main website, your account’s Auth0 redirect settings must point to the portal domain. That includes the allowed callback URLs and the application’s URI. Similarly, returning a member to the specific event or page they started from after signing in through an outside login flow only works if that outside login flow preserves a return-URL parameter pointing back to that destination. The exact parameter and behavior depend on how the outside login integration was built, so confirm it with whoever built the integration instead of assuming it happens automatically.
Not every authentication integration also synchronizes data. Some are sign-in only. They let members authenticate between an outside product and the member portal using OpenID Connect, with nothing else shared between the two systems. Do not assume a connected sign-in integration is also keeping records in sync. Check what that specific connection does.
Tip
A mobile app cannot authenticate a member using Google sign-in from inside its own in-app browser view. Google requires the login to open in the device’s external browser and then redirect back into the app. If Google sign-in fails only inside a mobile app, check whether the developer built the flow this way.
The same email address can map to more than one identity in Auth0 when your account has more than one sign-in method enabled. For example, email and password, Google, and LinkedIn can each create a separate identity for what looks like the same email. Rhythm can still map those identities to the same contact record, but an integration that assumes one email always means one identity may be surprised by this.
WordPress Integration
WordPress is one of the more common platforms for a self-hosted association website, and Rhythm supports it in two related ways: a general WordPress plugin and Auth0-based single sign-on between WordPress and your Rhythm account.
The WordPress plugin works with one or more WordPress instances tied to the same Auth0 setup and Rhythm account. A site hosted on a subdomain does not behave differently for this integration. What matters is whether it is another WordPress instance connected to the same setup, not its address. You do not need direct access to your Auth0 configuration to start the WordPress integration, because Rhythm can begin the work without it. If you need access to the plugin itself rather than the identity-provider configuration, that access can be set up even though direct Auth0 access is not offered. Make sure you are asking for the right kind of access.
Before you install the Rhythm WordPress plugin, your WordPress site needs the Auth0 WordPress plugin installed and configured for your Rhythm account’s Auth0 setup. The Rhythm plugin depends on it. Engineering generally recommends the Auth0 plugin for WordPress single sign-on. You can configure it with explicit authorize, token, and userinfo endpoints, or with your account’s OIDC discovery URL. Both are valid starting points, and the WordPress plugin documentation covers both setup paths. If your goal is portal-related sign-in on a WordPress site, start with the WordPress plugin documentation instead of the general API documentation, because it is the better starting point for that scenario.
For this integration pattern, the responsibility is usually split the same way. Rhythm adds the callback and allowed URLs to the Auth0 application, or to the related API-key configuration, on its side. Your website team configures the WordPress-to-Auth0 connection on theirs. Rhythm generally does not run the full third-party website implementation directly. Along with the client ID, client secret, and Auth0 domain, you need to provide the allowed callback URL and allowed logout URL so Rhythm can add them. The credentials alone are not a complete setup.
If you need to customize how an incoming Auth0 profile matches an existing WordPress user, use the WordPress Auth0 plugin’s supported hook for selecting the user in a custom or must-use plugin. Do not modify the plugin core. When matching, prefer an immutable Rhythm contact or user identifier over email. Email addresses can change, and matching on email risks creating a duplicate account when they do. The same reasoning applies to matching by name. For some social sign-in scenarios, redirect problems are typically caused by Auth0 account linking not being active. If members using more than one sign-in method run into unexpected redirects, check whether account linking needs to be turned on.
Warning
If a WordPress site is not using the supported Rhythm WordPress plugin, a custom integration may not reproduce the plugin’s behavior for a contact with more than one login. The supported plugin manages WordPress roles automatically on sign-in, while a custom plugin’s own logic may not handle that the same way. If you see login or role problems tied to multiple logins on one contact record, check whether the site is actually running the supported plugin before assuming it is a general platform issue.
Members can also hit a same-email sign-in error before reaching the sign-in prompt on a WordPress-based homepage login if the site does not account for one email having more than one Auth0 profile. A website developer who maintains that kind of login should handle that scenario explicitly.
Other website platforms follow the same Auth0-based pattern with their own extra steps. A Sitefinity-based site, for example, needs logout-chain coordination configured on both the Rhythm side and the Sitefinity side, in addition to the usual Auth0 application. When it is unclear which parts of a Sitefinity login flow come from Rhythm and which are configured in Sitefinity, check both the Auth0 application already present in your account and Rhythm’s published integration documentation for that platform before assuming no connector exists.
Outlook Integration
The Rhythm Outlook integration is a web-based add-in, not the older kind of add-in built directly into desktop Outlook. It works the same way in the desktop Outlook client and Outlook on the web. You can use it to associate email correspondence from Outlook with the matching contact record in Rhythm CRM, so conversations stay connected to the right record. It has also grown to support composing emails with Rhythm Assistant directly inside Outlook.
In Outlook on the web, the add-in’s button appears on the toolbar above the message when you are reading or composing it. It does not appear on the left side, where Outlook shows Apps. Look for an add-in, not an app. In Outlook, those are different things, and looking in the wrong place is a common reason people cannot find the button. The button can also be hidden from the toolbar after installation. If you do not see it, you may need to customize the Outlook toolbar to add it before you can use the integration.
| Symptom | What to check |
|---|---|
| "Access Restricted" when signing in, even though the integration is enabled for your account | Account-level enablement does not always resolve one person’s access, so treat those as separate checks |
| Sign-in fails for one person but not others | Sign out and back in, compare behavior in Outlook Web and the Outlook Mac app, and try a separate account in the same Rhythm account to see whether the issue follows the person or the client |
| Sign-in fails, but the same record loads fine when Support reproduces it from the back end | This points to something specific to the affected sign-in or account rather than a Rhythm account-wide problem; testing with a different account in the same environment helps confirm that |
In at least one case, an Outlook sign-in failure happened because the sign-in step’s background lookup returned more account data than that step was built to handle. The lookup was reworked to return only the two fields it needed. If sign-in fails consistently for one account and the checks above do not explain it, raise this kind of backend mismatch with Support.
Webhooks, Zapier, and Event Streams
For real-time outbound integrations, such as sending membership, renewal, or registration activity to an outside system as it happens, start with Rhythm’s Hooks documentation. A webhook only sends data out when something happens in Rhythm. It is not a way to pull external reference data into Rhythm, and it cannot replace a built integration when you need a one-way sync from an outside service into Rhythm. If one webhook does not cleanly cover the use case, such as when you need to send data to more than one downstream tool or need richer handling than a direct webhook call provides, Zapier and Event Streams are the backend trigger framework built for that. Moving to that framework is often cleaner than trying to stretch a direct webhook further.
Zapier support has grown to include write-backs into Rhythm, not just one-way sync out. Its outbound triggers are also expected to extend to more record types over time. New job postings, new event postings, form submissions, new members, and press releases have all been discussed as scenarios Zapier can bridge to outside sites, in addition to what it already supports. If a trigger you need is not available yet, check with Rhythm support on current availability instead of assuming it is not planned.
When an outside system needs to POST data into Rhythm, be clear about which URL is being requested. A URL formed from your Auth0 domain plus /oauth/token is the token endpoint used to get an access token. It is not a general-purpose inbound URL. If a third-party developer needs somewhere to POST JSON so Rhythm can write it back into a record, that is a different Rhythm-managed endpoint. Building it is not always a standard self-service setup. It can involve creating new custom endpoints and deciding how the incoming data should be stored, may depend on what was contractually committed, and can carry its own cost or require a custom integration scope. Route that kind of request to Rhythm support instead of assuming the token URL is the answer.
Matching and Verifying Records Between Systems
An integration that matches or verifies records against Rhythm should usually prefer Contact ID over Contact Number. Contact ID is the stable, unique identifier for a contact record and is the preferred field for integration matching. Contact Number is more likely to have been used historically by an integration configured before this distinction was clear, but Contact ID is the field to use going forward.
When an outside system does not store Rhythm’s own identifiers, such as an outside learning platform with no field for a Rhythm contact ID, match imported records by a combination of shared fields. Email, first name, and last name are an accepted way to link records when there is no better option.
For an integration that needs one combined name instead of separate first and last name values, use the default contact name field. Do not reconstruct the name from first and last name separately. The default field is the one Auth0-based flows already treat as the primary name value, and using it keeps the integration in sync automatically when a member’s name changes.
Warning
Contact status and membership status are different signals, so an integration should not treat one as a substitute for the other. A contact can stay active in Rhythm even when that person is not currently an active member. If an outside system reads contact status and reports it as membership status, non-members can appear active there. Point the integration at membership status specifically.
Membership status text is not guaranteed to look identical everywhere you retrieve it. A report or query can return a capitalized label, while looking up one record directly can return the same status in lowercase. Design your integration to normalize the value it receives instead of matching against one exact text form. Prefer the documented, stable value the API defines over a label meant for display in a report. An outside system can also verify a person’s membership status in real time, rather than relying on an export, by authenticating with a machine-to-machine Auth0 application and calling the API with an identifier such as email.
Exported query data is only current as of the moment you exported it. If you import query results into an outside platform instead of maintaining a live integration, a record merged in Rhythm afterward can still show as a duplicate in that outside platform. The export does not clean that up automatically. Duplicate checking between what Rhythm exports and what an outside platform imports needs to happen in that platform’s own workflow.
Warning
When you merge duplicate contact records, keep the record that holds the sign-in identity, which is the one tied to Auth0, as the primary record. If the record removed during the merge is the one with the login, the person can be unable to sign in afterward. This matters for any integration that depends on that person’s sign-in continuing to work, not just for Rhythm itself.
If accounts created through an integration end up with a sign-in but missing profile details, such as email or address, check the account-creation step on the integration side. The integration may not be collecting those fields, which means there is nothing for Rhythm to pass through to the connected system even though the account was created successfully.
What Happens If You Lose Access to an Integration
Some integrations are enabled for your account individually. If that access is later withdrawn, Rhythm keeps any connection you already created for that integration. For example, with an OpenWater connection, you can still view and delete the connection, but you can no longer edit it. Rhythm will refuse even a rename and show a message that your account does not have access to enable that integration. After access is gone, deleting the connection is the only way to remove it from the list. The control that manages your account’s access to an integration mainly prevents editing, not necessarily whether an already configured connection keeps working. Because that check happens when you save, not when you read the connection, a connection you saved while you had access can keep operating after access is withdrawn, right up until someone tries to change it.
Other integrations are generally expected to follow the same rule: you cannot create or edit a connection’s configuration without access to that integration. This includes ActiveCampaign, Higher Logic, QuickBooks Online, Zoom, and Mailchimp, among others. However, only the OpenWater behavior above has been directly confirmed end to end. If you see different behavior on another integration’s settings page, treat what that page tells you as more authoritative than this general expectation.
Tip
If a connection’s settings page refuses every change and shows a message about not having access to the integration, your account’s access to that product may have been withdrawn. Contact Rhythm support to confirm or restore access. This kind of message can also appear when you first try to authorize an integration, such as Zoom, not only after you have already connected it. In that case too, the cause is usually missing access for your account, not a sign-in problem with the outside product.
Reconnecting an Approved Connection
For a connection you created by approving Rhythm at the outside platform, you do not need to approve it again on a fixed schedule. If that type of connection stops working, such as when the outside product shows Rhythm as no longer authorized, look for a Reauthorize control on the connection’s settings page. Use it to go through the approval step again and restore the connection without deleting and recreating it.
Troubleshooting Sign-In and Access Problems
When members or staff report they cannot get into something connected, separate two questions before you troubleshoot further. Are they failing to sign in at all, or are they signing in successfully and then being blocked from specific restricted content on the connected system? Those point to different causes and fixes, and one ticket can quietly mix the two if you do not ask early. It also helps to check whether the issue affects one person or several, and whether the affected system lives outside Rhythm entirely or is only linked through the portal.
For a single sign-on integration, validate the identity claims separately from what a downstream API call does with them. A newly created account’s ID token containing the expected identity claims and that same account’s access token successfully calling a contact-related endpoint are two different pieces of evidence. The first shows Rhythm sent the right claim. The second shows a specific API call is handling it correctly. Do not assume confirming one also confirms the other.
If a sign-in failure happens after a redirect to a third-party system, and Rhythm’s Auth0 side is issuing tokens successfully, the failure most likely lives in how that third-party vendor built its end of the sign-in flow. In that case, no Rhythm-side change is likely needed, and troubleshooting continues with that vendor. Similarly, a token can be valid, issued successfully by your own or a customer-managed Auth0 setup, and usable for other API calls, while still being denied at one specific endpoint. That is an authorization problem at that endpoint, not proof that the token is bad. A 403 on a commerce-related API call from an external site can happen the same way. If the call relies on a signed-in end user’s token instead of a broader authorization context, and that user does not have access to the requested resource, the call fails even though authentication succeeded.
An older account-creation flow used to let a person start sign-up from an outside, SSO-connected system before their Rhythm contact was linked. That could give the outside system a user with no linked contact and cause an error there. The current flow redirects the person to create or link their contact first, then sends them back to the outside system to avoid that failure.
If a specific page or piece of content behind a login is inaccessible, the cause is not always a Rhythm record problem. It can be on the outside website or in the authentication layer between the two systems. Check for recent changes on the outside website around the time the problem started before assuming it is a Rhythm-side issue. Deleting and recreating an authentication profile is sometimes used as a workaround for this kind of problem, but it does not reliably fix it, so do not treat it as a first resort.
For some sign-in and integration problems, Support may need Rhythm’s integration engineering team to review logs and internal details that Support cannot access directly. This can make a deeper investigation take longer, so set that expectation with anyone waiting on a resolution.
Where to Set Up Each Kind of Connection
Each integration’s settings page explains what that connection stores and controls. Start from the catalog of available integrations, or use the setup checklist if you are configuring your account for the first time. Both list every connection your account can make and link to its settings page.
Warning
A generic API endpoint or protocol is not, by itself, a supported customer integration path. Before you build against one, confirm that Rhythm has enabled it for your account and published setup guidance for it. An endpoint that exists but has not been enabled and documented this way is not customer-ready yet, whatever else it might be capable of.
Not every product you might want to connect has a supported path yet. If you are looking for a specific integration and do not find it:
- A single-click handoff into a third-party site, ticketed URL, or SSO-style access from Rhythm to an outside publisher can look like a standard integration request, but it may require scoped integration work, developer resources, and coordination through customer success. It is worth asking instead of assuming it is a quick configuration change.
- Rhythm has no direct integration with a WordPress map or “find a member” plugin. Exchanging data with a feature like that has to go through the API instead of a built-in connection.
- The Google Civic integration was discontinued, and there is currently no alternative offering that provides similar functionality in its place.
- PropFuel has never been a direct, native Rhythm integration.
What to Expect from Monitoring and Outside Changes
Rhythm has monitoring and alerting across the platform for many kinds of service interruption and processing failure connected to integrations, but no monitoring system catches or prevents every possible failure. If something seems to have silently stopped working, do not assume it would have been caught automatically. Report it instead of waiting for an alert that may not come.
Occasionally, a brief integration interruption happens around the same time as scheduled platform security updates. When that happens, it typically resolves on its own without anything you need to do, and this kind of impact during business hours is not a normal expected occurrence. Separately, if an integration you depend on changes behavior because the outside vendor retired or changed its own API, that is a change in the product you are connecting to, not a defect in your Rhythm setup. It may take time to identify an outside dependency as the actual cause instead of something wrong on the Rhythm side.
Warning
A long session title can be truncated and become a session identifier used by some external mobile integrations, which enforce a roughly 50-character limit of their own. A title-based identifier that exceeds that limit can make the session unusable in that integration. Keep session titles reasonably short if you use one of these integrations.