copyright | lastupdated | keywords | subcollection | ||
---|---|---|---|---|---|
|
2024-04-18 |
event-notification, event notification, faqs, Frequently Asked Questions, question, billing, service, invalid devices, device deletion, database |
event-notifications |
{{site.data.keyword.attribute-definition-list}}
{: #en-faqs-operations}
FAQs for {{site.data.keyword.en_short}} provide answers to common operations issues. {: shortdesc}
{: #faq-en-message} {: faq}
Sometimes messages are reported as delivered but are not received by the user for the following reasons:
- They are rejected by the telecom operator. If the same message is repeated over a span of time, messages are classified as SPAM message by the operator.
A resolution is to add any TransactionID
or ReferenceID
to the message body. These IDs classify the SMS as transactional, and is not blocked by the operator.
- The user opts out. If the user opts out from messaging by sending opt-out text like
Opt Out
,Stop
, orExit
, then messages do not reach that user and the status report states that. The user can send anOpt in
message to the same source to restart receiving messages.
{: #faq-en-invalid-device-deletion} {: faq}
Sometimes, devices are marked as invalid and deleted from the database, if they meet these invalid conditions:
-
FCM or Android devices:
invalidRegistration
- might be due to incorrect registration token format passed to the server.MismatchSenderID
- a mismatch in the senderID who is not part of the user group that is tied to a registration token.NotRegistered
- an invalid registration token due to various reasons (like client app getting unregistered with FCM, tokens are invalid, registration token expires, client app that is updated but the new version that is not configured to receive messages).
For more information, see FCM error response codes for downstream messages{: external}.
-
APNS or Safari devices:
Unregistered
- the device token is not active for the specified topic.BadDeviceToken
- the specified device token is invalid.DeviceTokenNotForTopic
- the device token doesn’t match the specified topic (bundle ID).
For more information on how to handle notification responses from apps, see here{: external}.
-
Chrome or Firefox devices:
NotFound
- the subscription is expired and can’t be used.Gone
- the subscription is no longer valid.
For more information, see web push protocol{: external}.
{: #faq-en-topic-tag-subscriptions} {: faq}
-
{{site.data.keyword.en_short}} topic subscriptions:
For the topic subscriptions, start by creating a Topic and write conditions on that topic. This topic is responsible for routing the incoming notification that satisfies the topic conditions.
You can subscribe to multiple {{site.data.keyword.en_short}} destinations like email, SMS, webhooks, slack, and Microsoft teams. Also, you can subscribe push type destinations like android, iOS, Firefox, chrome, and safari.
If the incoming notifications satisfy the condition written for Topic (T), it routes the notification to all the destinations subscribed or connected to Topic (T) irrespective of the type of destinations.
For example,
ACME
Bank wants to route maintenance event notifications to customers by using android and iOS devices. Acme Bank is following these steps:- Create a topic named
ACME-Maintenance
. - Write Advance condition
$.notification-type == 'maintenance'
. - Subscribe push android and push iOS destinations to your topic.
- Next, send an event notification with payload containing attribute
"notification-type":"maintenance"
and"ibmenpushto": "{\"platforms\":[\"push_android\",\"push_ios\"]]}"
,notification-type
attribute is added so that it matches against the topic condition andibmenpushto
for targeting customers with android and iOS devices. - {{site.data.keyword.en_short}} will get routed to customers with android and iOS devices, since its payload contains
"notification-type":"maintenance"
which matches the condition for TopicACME-Maintenance
and"ibmenpushto": "{\"platforms\":[\"push_android\",\"push_ios\"]]}"
asibmenpushto
is mandatory for push type {{site.data.keyword.en_short}} destinations.
All push devices will get registered under {{site.data.keyword.en_short}} destination of type push. For example,
push-android
,push-ios
, and others. {: note} - Create a topic named
-
{{site.data.keyword.en_short}} tag subscriptions to push devices:
For example,
ACME
Bank wants to route maintenance event notifications to customers by using android and iOS devices. ACME Bank maintenance usually takes place in one region at a time.ACME Bank wants to register each of their customer's android and iOS devices under region-specific tags.
-
To achieve this the bank can use {{site.data.keyword.en_short}} Android Client SDK and iOS Client SDK to subscribe to
Asia Pacific
customers' android and iOS devices under theAP
tag.Use the following links to learn more about how to subscribe to push devices by using the {{site.data.keyword.en_short}} client SDKs:
-
Next, the bank sends a notification with payload containing attribute
"notification-type":"maintenance"
and"ibmenpushto": "{\"tags\":[\"AP\""]]}"
,notification-type
attributes is added so that it matches against the topic condition andibmenpushto
as the message is for targeting push customers with android and iOS devices in Asia Pacific regionAP
.
-
Why don't I see Email or SMS notifications that I have sent after configuring {{site.data.keyword.en_short}} for Email and SMS?
{: #faq-en-message-email-sms} {: faq}
Email and SMS are supported only for {{site.data.keyword.IBM_notm}} Managed Sources ({{site.data.keyword.cloud_notm}} services). You can send a notification from API source to all other destinations, except Email and SMS.
{: #faq-en-slack-destination} {: faq}
{{site.data.keyword.en_short}} supports the Slack destination using Slack's “Incoming Webhook” feature. An incoming webhook is linked directly to a Slack channel. Hence, there is no need to separately specify the Slack channel.
Is it possible to customize the message that is generated from {{site.data.keyword.cloud_notm}} services ({{site.data.keyword.cloud_notm}} sources)?
{: #faq-en-sms-customize} {: faq}
You cannot customize messages that are generated from {{site.data.keyword.cloud_notm}} services ({{site.data.keyword.cloud_notm}} sources). These notifications are generated by the respective {{site.data.keyword.cloud_notm}} service such as {{site.data.keyword.secrets-manager_short}}, and {{site.data.keyword.compliance_short}}. The message content cannot be modified by the end user before it is sent out to a destination.
{: #faq-en-send-notification-error-422} {: faq}
{{site.data.keyword.en_short}} service is unable to process your request. This is usually seen when there is no condition or filter associated with the topic to which the notification is sent. Check your topic and verify that it is connected to the correct source, with the intended conditions.
Why my email notifications sent didn’t reach customers even though in the logs I can see successfully sent notifications?
{: #faq-en-email-notifications-missing} {: faq}
This may be due to your {{site.data.keyword.en_short}} instance has a subscription created for the smtp_ibm destination and has no email ID added as a recipient to the list for the subscription.
Make sure your {{site.data.keyword.en_short}} instance has a subscription created for the smtp_ibm destination and has at least one email ID added as a recipient to the list for the subscription.
{: #faq-en-notifications-multiple-destination} {: faq}
Yes. You can send notifications to more than one destination.
What is the difference between a custom domain email destination and an IBM Cloud email destination for event notifications?
{: #faq-en-notifications-email-destinations} {: faq}
Emails sent via an IBM Cloud email destination are sent on behalf of IBM Cloud from a source (i.e., The sender's email domain will always have ".event-notifications.cloud.ibm.com"). On the other hand, a custom email destination allows you to add your own domain address through which a sender can send emails.
Also, API sources cannot send notifications to IBM Cloud email destination, because of the security reasons, on the other hand, a custom domain email destination can receive notifications from any kind of source.
{: #faq-en-notifications-spf-verification} {: faq}
SPF (Sender Policy Framework) verification is an email authentication method designed to prevent email spoofing and phishing by allowing email recipients to verify that an email message originates from an authorized source. SPF works by defining a list of authorized mail servers (IP addresses) for a particular domain. When an email is received, the recipient's mail server can check whether the sending mail server's IP address is on the list of authorized servers for the sender's domain.
SPF helps prevent unauthorized sources from sending emails on behalf of a domain, reducing the likelihood of phishing attacks and spam. However, it's important to note that SPF alone does not provide end-to-end email security. Other email authentication mechanisms, such as DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting, and Conformance), are often used in combination with SPF for a more comprehensive email authentication and anti-phishing strategy.
{: #faq-en-notifications-dkim-verification} {: faq}
DKIM (DomainKeys Identified Mail) verification is an email authentication method used to verify the authenticity and integrity of email messages. DKIM helps prevent email spoofing, phishing, and tampering by allowing email recipients to check whether an email message was sent from an authorized source and whether it has been altered during transit.
DKIM verification provides a strong mechanism for email authentication because it cryptographically verifies the sender's identity and ensures the email's integrity. It's often used in conjunction with other email authentication methods like SPF (Sender Policy Framework) and DMARC (Domain-based Message Authentication, Reporting, and Conformance) to provide a comprehensive email security framework.
By implementing DKIM, domain owners can increase the trustworthiness of their email communications, reduce the likelihood of their domain being used for phishing attacks, and improve email deliverability.
{: #faq-en-notifications-spf-verification-works} {: faq}
-
The sender publishes an SPF Record: The owner of a domain (the sender) publishes an SPF record in their domain's DNS (Domain Name System) records. This SPF record specifies which mail servers are authorized to send email on behalf of that domain.
-
Email Sent: When an email is sent from that domain, the recipient's mail server may perform an SPF check by looking up the SPF record for the sender's domain.
-
SPF Record Check: The recipient's mail server checks if the IP address of the sending mail server is listed in the SPF record as an authorized sender. If it is, the email is considered legitimate; if not, it may be marked as suspicious or rejected.
-
Result: The SPF check produces one of three results:
- Pass: The sending server's IP address is listed in the SPF record, indicating that the email is legitimate.
- Fail: The sending server's IP address is not listed in the SPF record, suggesting that the email may be unauthorized.
- Soft Fail: The SPF record suggests caution, but the email is not immediately rejected.
{: #faq-en-notifications-dkim-verification-works} {: faq}
-
Message Signing: When an email is sent from a domain that has DKIM enabled, the sending mail server digitally signs the email message using a private key. This signature includes information about the email's content and the sender's domain.
-
DNS Record: The sender's domain publishes a DKIM public key in its DNS (Domain Name System) records. This public key is used by receiving mail servers to verify the signature applied in step 1.
-
Email Transmission: The email is transmitted to the recipient's mail server.
-
DKIM Verification: Upon receiving the email, the recipient's mail server performs DKIM verification by retrieving the DKIM public key from the sender's DNS records using the domain found in the "From" header of the email.
-
Signature Verification: The recipient's mail server uses the DKIM public key to verify the digital signature on the email. If the signature is valid, it means that the email has not been tampered with during transit and that it originated from an authorized source.
-
Result: The DKIM verification process results in one of the following outcomes:
- Pass: The email's DKIM signature is valid, indicating that the email is legitimate and hasn't been tampered with.
- Fail: The DKIM signature is invalid or missing, suggesting that the email may be suspicious or forged.
{: #faq-en-notifications-email-personalization} {: faq}
Email personalization refers to the practice of tailoring email content and messaging to individual recipients or specific groups of recipients based on their preferences, behaviors, demographics, or other data. The goal of email personalization is to create more relevant and engaging email experiences for recipients, which can lead to higher open rates, click-through rates, and conversions.
{: #faq-en-notifications-template-types} {: faq}
There are two types of templates: Invitation templates and Notification templates. An Invitation template is used to send customized email invitations to all those added to the subscriptions, while a Notification template is used when sending an email for an event. It can include HTML tags, handlebars support, and personalization support.
{: #faq-en-notifications-timeout} {: faq}
A client timeout refers to the period during which a client (such as a web browser or application) waits for a response from a server. If the server fails to respond within this specified time frame, a timeout occurs, indicating that the connection has been lost or the server is unresponsive.
{: #faq-en-notifications-why-timeout} {: faq}
Client timeouts can occur due to various reasons, such as slow network connectivity, server overload, misconfigurations, or issues with the client-side application. When a client doesn't receive a response from the server within the defined timeout period, it assumes there's a problem and terminates the connection.
{: #faq-en-notifications-cause} {: faq}
You may encounter client timeouts when trying to access a website, application, or service. Common indicators include error messages like Connection Timed Out
or Request Timed Out
. Monitoring tools and logs on the server side may also provide insights into timeout occurrences.
{: #faq-en-notifications-client-timeout-troubleshoot} {: faq}
- Check your internet connection: Ensure that your internet connection is stable and not experiencing any disruptions.
- Verify server status: Confirm that Event Notification Service is available and no incidents have been reported.
- Adjust timeout settings: Some applications allow users to adjust timeout settings. If possible, consider extending the timeout duration to accommodate potential delays.
{: #faq-en-notifications-timeout-address} {: faq}
Developers can implement various strategies, including optimizing code for better performance, utilizing asynchronous programming, and implementing retry mechanisms. Additionally, providing users with clear error messages and guidance on troubleshooting can enhance the overall user experience.
{: #faq-en-notifications-client-timeout-server} {: faq}
Not necessarily. While server-related problems are common causes of client timeouts, issues on the client side, such as network problems or misconfigured settings, can also contribute to timeouts. It's essential to investigate both client and server aspects when troubleshooting timeout issues.
{: #faq-en-notifications-client-timeout-action} {: faq}
If you consistently encounter client timeouts, consider reaching out to the support team.