ÃÛ¶¹ÊÓƵ

Transcript

Hello everyone. Welcome to our REST API v2 webinar. My name is Alex Fonduyano and I’m a customer success engineer with ÃÛ¶¹ÊÓƵ PaaS. Today I’m joined by some of the engineers who built this new API and together we’ll cover what’s changing, why it matters, and what you must do to migrate successfully. Beyond just reviewing the changes, our goal is to ensure you leave with a clear roadmap for your migration process. So let’s begin by outlining today’s agenda. What we’ll cover today, overview and benefits of REST API v2, why we built it and why it matters, migration steps to guide you through the transition process, a basic flows walkthrough demo to see how it all works in practice, the timeline and milestones to stay on track for the decommissioning of v1, next steps and resources to help you after today’s session. At the end we’ll have a question and answer session where we’ll cover both pre-registered set of questions and some live questions. So feel free to drop your questions in the chat anytime as we’ll address them toward the end. Now let’s dive into the big picture. When we designed REST API v2, the goal was to build a modernized, streamlined and flexible authentication framework that would meet both the current and future needs of the TV industry. And here are the core ideas that make up this new API. It’s catered for modern architecture as the underlying infrastructure was optimized to support multiple device scenarios and high demand events like Olympics, Super Bowl or March Madness. This ensures performance remains stable across devices even when traffic spikes. We’ve extended the DCR layer, dynamic client registration as you know it, across all features. This means your apps benefit from improved encryption, better session consistency and more granular access control. With the flexible auth options, REST API v2 allows users to switch between different profiles like MVPD logins, temp passes and D2C accounts without repeated sign-ins. This flexibility makes it much easier to implement hybrid business models without complex workarounds. We have simplified the flows, the standardized endpoints with v2. They structure across the board. There are fewer endpoints and the flow design is much more consistent. With this, the result is that it’s less time spent maintaining integrations and fewer opportunities for flow specific bugs. We’ve improved the control of all authentication as REST API v2 enhances authentication session management giving developers greater control over how and when the user sessions are refreshed or invalidated. While a single centralized command isn’t in place yet, the new framework lays the foundation for broader session control across devices. Unified RESTful API for all platform means that we retire the access neighbor SDKs and replace them with a unified REST interface. As this API works seamlessly across web, mobile and connected TV environments. This covers our architectural and functional improvements. How do these changes help in practical use cases? Well, let’s see where REST API v2 shines. A major improvement is support for multiple authentication profiles within the same session. Previously users had to logout and backend when switching between MVPD credentials, direct to consumer subscriptions or temp passes. With REST API v2, users can move seamlessly between the same session without breaking their own session. This is especially useful for apps that offer D2C subscriptions alongside MVPD authentication. They implement time-based access passes and they need a smooth transition between temporary and permanent authentication methods. You can see how this simplifies the user experience. For the cross-device SSO, this solves one of the biggest pain points, having to log in separately on each device. With REST API v2, users can start watching on mobile and continue on smart TV without entering credentials again and move seamlessly between different platforms within the same ecosystem. This improvement is especially important for multi-device households or users who switch frequently between mobile, desktop and TV screens. Extended error information. One of the biggest pain points in MVPD integrations is debugging authentication or authorization failures. With REST API v2, we can provide extended information across all of the endpoints, the authentication requests, the pre-authorization checks. Previously, the detailed error feedback was limited to pre-auth calls. Now, error codes are more consistent and there’s a lot of information across all the API flows. Why is this important? Because now developers can diagnose issues faster without needing trial and error debugging. Support escalations are reduced since many common issues can now be handled on the implementation side and ultimately, MVPD specific errors are clearer, making it easier to pinpoint where failures occurs. This bed of visibility into errors allows teams to proactively resolve issues before they impact end users. These are just a few of the ways REST API v2 unlocks new capabilities. Now, let’s look at the migration steps and what’s involved in making this transition. Create a new registered application. You can start by registering a new app with REST API v2 scopes. These scopes define how your application requests authentication authorization and should be set based on service entitlements, supported authentication models. You can reuse existing configuration. Many elements of your existing setup remain valid and can be reused, including service provider identifiers, MVPD authentication mappings. This reduces the need for re-implementation. Force definition. This helps streamline migration while reduces the need for major reconfiguration. You can configure application settings. While most configurations remain unchanged, some settings may require adjustments like authentication protocols if needed, TTL settings. These will align with new session expiration rules, profile handling and authoritative access validation. These ensure session decisions are made correctly based on user identity and entitlements. Maintaining device identification. Your existing device identification frameworks remain fully compatible with REST API v2. This means no changes are needed for device recognition and your current device identification logic will work as expected. The migration process follows a structured set of phases designed to support clear session management and authentication decisions. Like registration, where you set up client app and define scopes. Configuration, where you adjust settings to align with profile-based authentication models. Authentication, you can establish a session validation and identity verification flow. Pre-Auth, you can request an authoritative decision before granting access. Authorization, confirm access entitlements where no separate media token is required. And ultimately logging out. Explicitly terminate session when needed, ensuring proper session control. Now, as I’ve outlined the migration roadmap, let’s move to a demo where we’ll walk you through a demo that shows how REST API v2 handles user logins, how it manages MVP requests. But remember, please send your questions in the chat during the demo. We’ll get to them shortly.

Hello everyone, and welcome to today’s demo. My name is Catalin Grigoré, and I’m excited to walk you through our new REST API v2. We have about 15 minutes for this session, during which I’ll demonstrate the API’s basic functionalities. Feel free to drop any questions in the chat as we’ll try to address them today or follow up afterward. Before we jump into the API calls, let me quickly highlight some key resources that I’ll be using throughout the demo. First, the ÃÛ¶¹ÊÓƵ PaaS Authentication public documentation. That’s made available on experienceleak.adobe.com where you can find API references, flows, cookbooks and many more. Second, the ÃÛ¶¹ÊÓƵ PaaS Authentication developer website. That’s hosted on developer.adobe.com, which we’ll assume is a real TV application for today’s demo. Finally, I will be using predefined synthetic values for HTTP parameters and headers prepared in advance for this demonstration, based on the guidelines in the public documentation. Among key request parameters that I would need, I am mentioning the service provider. This is the programmer channel identifier established during onboarding with ÃÛ¶¹ÊÓƵ PaaS. The MVPD. This identifies the user’s TV provider. The redirect URL. This specifies the final destination where the user lands after completing an authentication or a logoff law involving browser redirects. The resources that represent the programmer’s content identifiers uniquely defined through agreements with MVPDs. While, for key request headers, I want to mention the AP device identifier header that identifies the user’s device, the X device info header that provides details about the device, the authorization header that contains a bearer token obtained through the DCR API, where DCR stands for Dynamic Line Registration and serves as a security mechanism to access our APIs. Each of these headers is extensively documented in the appendix section of our public documentation, including examples of how to complete them correctly. Before we begin the user journey, I’ll quickly demonstrate how to obtain an access token via the DCR API. First, we need to obtain client credentials.

This client credentials must be cached indefinitely by the TVA application. Next, we use these credentials to retrieve an access token.

This token will be used as a bearer token in the authorization header for all subsequent API calls. It’s important to note that access tokens have expiration times, meaning they must be refreshed periodically. Now, let’s move into the first step of the user journey, when a user opens the app for the first time. When a user opens the TVA application, the first thing the app needs to do is check whether the user is already authenticated. To do this, the app makes a profiles request. If the user has never signed in before or if a previous one expired, the API will return an empty profiles map. At this stage, the app should prompt the user to sign in. Now let’s see how the app retrieves a list of available TV providers so the user can select one. Once the user clicks the sign in button, the app must allow them to choose their MVPD. For displaying the MVPD options, the app queries the configuration API to retrieve a list of available MVPDs based on active integrations. The app then presents this list as a selection screen for the user. If the app cannot display this selection screen due to platform constraints, then a second device also referred as a second screen must be used instead. However, we will not cover that scenario in today’s demo. Now let’s move to the authentication step where the user logs in. After selecting an MVPD, the app must initiate authentication by creating an authentication session.

The API response includes three key fields that dictate the next step, the action name, the action type, and the URL. In the current scenario, the app opens a browser and navigates to the provided URL where after a series of red effects, the user will enter their credentials. If the app cannot open a browser component due to platform constraints, then authentication must be performed on a second device. As before, we will not cover that scenario in today’s demo. Now we need a way to check whether the login was successful. Once the browser reaches the previously provided redirect URL, the app can start to pull the profiles API using the authentication code until the user profile is returned or until the authentication session expires. Mine the authentication session not after timestamp. Once authentication is complete, the response will contain the user profile for the selected MVPD. The user profile timestamp for the not after field is determined by the authentication time to leave decided together with the MVPD. At this stage, the app can cache either the MVPD identifier or the entire user profile depending on its needs. Storing the foot profile may be beneficial for enhanced user experience as user metadata is now included in the same response. Now that the user is authenticated, we can move to the pre-authorization step, which helps us determine what content the user may be eligible to view. The pre-authorization, also called pre-flight authorization, is an optional API. I will require the cached MVPD identifier and the resource identifiers for which the app needs pre-authorization decisions. The response will include non-authoritative decisions for each resource. For permit decisions, the app may display an unlocked icon. For denying decisions, the app may show a locked icon or decide to hide the content. If access is denied, the response will include an additional error field with details that may be passed by the MVPD. I want to emphasize that the pre-authorization decisions will not include a media token. Now that we know which content may be accessible, the next step is letting the user choose the content it wants to start playing. After the user selects the content before starting the stream, the app must make an authorization request. I will require the cached MVPD identifier and the resource identifier for which the app needs an authorization decision. The response will include this time an authoritative decision. A permit decision will include a media token. A denying decision will include an additional error field with details that may be passed by the MVPD. I want to emphasize the presence of multiple timestamps as part of a decision. The token level timestamp is determined by an ÃÛ¶¹ÊÓƵ setttl that is just long enough for the application to validate and use the media token when releasing the stream. On the other hand, the decision level timestamp is determined by the authorization time to leave decided together with the MVPD. This TTL also controls a cache on ÃÛ¶¹ÊÓƵ’s backend site where we store permit decisions to enhance performance for subsequent requests. Now that the user is watching content, what happens if they close the app and return later? When the user reopens the app, the first thing it needs to do is check whether the user is already authenticated. For that, it will query the profile’s API again, but since the MVPD identifier would be cached, the app can use it to retrieve the existing user profile. If the cached MVPD identifier is lost for any reason, the app can still retrieve the existing user profile by querying the profile’s endpoint that we used at the beginning of this demo.

As you can see, the app is already authenticated. The app can proceed directly to the pre-authorization or authorizations tab. What if the user decides to logout? Let’s look at how the logout API works. When the user chooses to logout, the app sends a logout request to remove the user profile. For MVPDs that support the logout endpoint, the app must also open a browser and navigate to a provided URL to fully complete the process. This way, the MVPD can clean user-related authentication information also on their site. In my case, the current MVPD does not have a logout template, so the API response confirms that the logout process is complete. The application does not need to take any further action. Let’s talk about error handling and how the APIs provide structured responses to handle different scenarios. The event of errors? The API responses will include structured error information by default. These errors follow a consistent model based on the Enhanced Error Coarse documentation, whether they are generated by the programmer, the ÃÛ¶¹ÊÓƵPass, or the MVPDs. For example, if the application calls the authorization API and the user is not authenticated, as it is right now, the API will return an error that clearly outlines the issue and provides guidance on how the application can recover.

In this case, the app needs to ask the user to authenticate. Conclude, in addition to the API references already mentioned, we’ve also prepared more in-depth insights within the flows and codebooks documents that we encourage you to go through. Thank you, Greg, for the demo. I’ll resume the presentation with the timeline that we have set for REST API v1 and Access Neighbor SDK decommissioning. At the end of December 2025, REST API v1 will no longer receive feature updates or enhancements. It will remain operational, but only critical security or stability fixes will be addressed. By May 2026, the Access Neighbor SDK will no longer receive updates or patches, while they may continue working with strongly recommended transitioning, as feature platform changes or OS updates could introduce compatibility issues. Finally, at the end of 2026 is the full end of life, where REST API v1 and the Access Neighbor SDK will be fully retired. Applications relying on these technologies will no longer function beyond this point. To avoid disruptions, we encourage customers to complete migration well ahead of this deadline. And now that you have a clear timeline, let’s go over the next steps to help you stay ahead of these decommissioning milestones. Here’s what you can do after this webinar. You can review the documentation, check out migration cookbooks, API guides, they are all available in ÃÛ¶¹ÊÓƵ Experience League. You’ll also find a steady FAQ section, cookbooks to migrate client to server, server to server, it’s all there. You can set up a sandbox environment and request a new software statement and this will help you test new flows without impacting production. You can use our own developer website that you have seen in the demo. And most importantly, you should establish a migration timeline and we recommend setting up regular syncs with our team to track progress. Zendesk tickets can be created for more complex issues, but the engineering team here is available for walking through any other bits of implementation that were not present until now. I’m going to switch to JD, our colleague. He will go through a couple of pre-registered Q&A questions. He’ll take the rest of the session and afterwards we will go through the live Q&A section. Thank you. Okay. Hi, my name is JD and I will go through the questions received before the session and the questions received via the Q&A chat. So let’s start with the ones received before the session. The first one, can I reuse existing DCR applications? In order to use the REST v2 endpoints, a new registered application is to be created via our TV dashboard and the new software statements must be downloaded in order to be used to obtain the necessary access token by following the dynamic client registration flow. In order to create these registered applications, you must contact ÃÛ¶¹ÊÓƵ Support and they will help you with this process. As soon as the registered applications are present in our TV dashboard, you can start downloading the software statements and use them inside your implementation. The next one, will SDKs be available for supporting REST API v2? Regarding this, what we’ve seen during the last few years is that customers are trying to move to RESTful implementations in order to reuse the same code across all applications and to eliminate the dependency on some platform capabilities. Following this pattern, the REST v2 offers a common implementation across platforms. There are no specific features for specific platforms. We are just providing an API presenting a unified set of flows and features to cover all client implementations. Another thing to notice here is that all existing applications, meaning the ones that are using the SDKs and the clientless ones, so the ones using the REST v1, have to be migrated to REST v2.

Next question, should I perform another call to get the media token? Well, that’s an important improvement that we’ve done in REST v2. There is no need to have a separate call for getting the media token. We are offering an endpoint called authorization decision endpoint, which returns a response containing all the necessary information to continue the flow. Meaning that if the decision is a permit decision, you will get information about the TTLs and the media token that can be used in order to start playing the stream. If the decision is denied, you’ll get an error message, like the one Alex referred in the slide about the error information being exposed from all the REST v2 endpoints. And eventually, a custom error message if the MVPD is returning such a message to our system. Now, when a new media token needs to be obtained, a call to the same authorization decision endpoint is performed and will make the necessary validations based on the decision found on our backend, and return a new valid media token. So in summary, there is no separate call for getting media token. It’s just the decision response that includes this piece of information. The next question, is there a way to migrate existing authentications? When we designed the REST v2, one of the main ideas was to move as much processing as possible on the server side. The reason behind this is to minimize the client implementation. The client implementation does not have to keep status information about authentication and authorization on its local storage. It just needs to send appropriate parameters and headers that are described in the REST v2 spec. The ÃÛ¶¹ÊÓƵ PaaS system will use this information, the headers and the parameters received, and generate the necessary user profiles and decisions based on the interaction with the MVPD endpoints. Following this, we will return the appropriate responses that include, as you’ve seen in the demo, fields like action name and action time where we are helping the developer establish what would be the next step after the call which was performed. Additionally, we are returning this kind of information so that the client application is not left in an inconsistent way. We just need to be sure that we are returning the proper fields in order to move on with the flow.

Considering all these reasons on this change in architecture, there is no direct compatibility between previous APIs and the REST v2. The user will have to re-authenticate when starting to use the REST v2 applications.

And the last one, do I still need to use pre-authorization and regular authorization? Or can I just rely on the pre-authorization for? So let’s start with the first question. Yes, the pre-authorization and authorization flows are still present in the REST v2. The difference is that they are coming under a new set of endpoints called decision endpoints. So there is an authorization decision endpoint and a pre-authorization decision endpoint.

The authorization call remains mandatory because we need to verify that there is a valid permit decision in our system. And the decision from our system is, of course, obtained via the call to the MVPD endpoint. And in case such a valid permit decision is found, a new media token is returned and the authorization flow can continue. The pre-auth Z has the same purpose, meaning that it helps the client application present the end user with a catalog of resources which are filtered based on the user entitlements. But in order to start playing the content, the application still needs to perform the decision authorization call.

Can I just rely on the pre-authorization call? Well, no, because the pre-authorization call should not replace the purpose of the authorization call. So pre-authorization is basically for painting the UI. The authorization call is for getting the media token that is necessary to start playing the content. And now I think that we can move to the Q&A window. So first question, when is V1? Will be deprecated. I think that Alex presented a slide earlier. The end of support for SV1 is at the end of this year and the Internet end of live is at the end of the next year.

So end of support means that the endpoints will still be up and running, but will not solve bugs or cannot open tickets or submit eventual problems that you see with the SV1. And another question, is it correct that there is currently not a way to refresh the profile? Just a second, please. The window got refreshed. So is it correct that there is currently not a way to refresh the profile to keep a user signed in when he or she regularly uses the account? The user could be interrupted between video playbacks and be promoted to login again when the active profiles expire in that case. What would be your suggestion in this scenario? Well, the profile information that we keep in our system is based on the interaction with the authentication and VPD endpoint. It’s basically the VPD owns the user account. He can check if the user submitted the proper credentials in order to continue to the authorization flow, so in order to play a specific resource.

So for this reason, we are contacting the VPD each time we need to initiate a new authentication endpoint. And then at the end of the flow, in case the user has submitted the proper credentials, we are using the response from the VPD endpoint, authentication endpoint, in order to generate the profile in our system. So in other words, the profile is generated on our side, but it uses the information received from the VPD endpoint.

So this is the reason why we cannot just automatically renew a profile. We still need to initiate the authentication flow with the MVPD. Now, if the MVPD would support such a scenario where there is no interactive login being displayed and they can just refresh the user profile and submit a response to our system, that’s something that’s a use case that is not supported by MVPD right now. And as far as I know, it’s also business discussion here. Our product team with MVPD product teams, it will need to come to a conclusion about such a support, but there is no such support at this time.

The next question. Next question.

I’m used to accessing every caching thing, so I don’t have to. Is there a best practice on what should be cached when? Yes. Well, we have a useful FAQ page, and that FAQ page contains indications or recommendations for migrating existing implementation to REST v2 implementation.

We also have cookbooks for client to server and server to server implementations of the cookbooks and the FAQ page will help you with this kind of information. Of course, you can ask additional questions or clarifications via tickets submitted to our ÃÛ¶¹ÊÓƵ support team.

To double check on the authentication migration, the next question. Just a second to refresh this. So to double check on the authentication migration, so even when programmers back-end send a session, just a second. So to double check on the authentication migration, so even when programmers back-end sends a session device identifier from v1 to the new profile standpoint, we’ll obtain an empty list and user would need to re-authenticate. As specified a bit earlier, there is no direct communication between a v1 and a v2 implementation. On the other hand, the device ID or the way the device ID is obtained right now in order to be used in REST v1 remains the same. So you are going to use the device ID or the same way you are getting the device ID and included in REST v2, but the device ID needs to be sent in a specific header and you’ll find in our documentation a section called headers where we are describing how this information should be sent in which format.

So, I’m going to show you a few examples of how to do this. So, yeah, the device ID stays the same, no communication between v1 and v2. The REST v2 authentication flow will start from scratch based on the information you are sending at that point, like device ID, device information, DCI information, and so on.

The next question, when using the service provider configuration, I got always, it was 401, can I use the API in another country other than the United States? Yeah, I don’t think that we have location-based security. The security mechanism used by the REST v2 is the dynamic client registration. So, create new registered application, download the software statement, use it in order to generate the client ID and the client secret, and then based on the client ID and client secret, generate or obtain an access token that is going to be included on each and every call to the REST v2 endpoints under the authorization header. Well, it’s pretty much a WAT2-based flow or security flow.

But yeah, I think that it would be useful in order to have a clear understanding of the situation, to submit these details in a ticket, and we’ll have a look for sure.

Okay.

The next question, I’m used to access enabling handling OSSO, does this mean I’m responsible for connecting? So, I’m used to access enabler handling OSSO, does this mean I’m responsible for connecting to Android, Apple, Fire TV, SSO, there was an SDK for Amazon devices. Do I need to connect with Amazon and recreate? The information that you extract from Amazon and submit it in order to have an SSO flow and that I think it’s a platform identification information, we still have that support in the REST v2. So, you’ll have to extract that information or obtain it and then send it in a header. Once again, the details on how to send or in which format to send that information to our endpoints can be found in a specific section of our documentation called headers. So, that SSO is supported via this platform identification.

Next question, can we have SSO meaning customer logs into one device and they can connect another device in our M2M integration? Yeah, well, we are providing as part of REST v2 a new way or a new method to perform single sign-on. It is a header called the ÃÛ¶¹ÊÓƵ service token and that header can be used in order to start authentication from the first device and then pull for existing profiles from the other device. So, the flow should be as follows. You are using that subject token in order to initiate the authentication flow on the first device.

You perform a successful login with a specific MVPD on that device and then when moving to the second device, you can pull for an existing profile by sending that specific or the same ÃÛ¶¹ÊÓƵ subject token. And if these conditions are met, yes, the profile is found from the second device. But that’s also something that we can clarify further via TKED because SSO is a more complex topic and we can understand this situation better if we get some more information in a TKED.

Just a second. So, the next question. We do use Cogent or Autogenerate code for us using Swagger. Why is not the token endpoint in the current Swagger definition? Well, there is no token in REST v2, meaning that we are using a set of different terms and you can find this kind of information in a glossary section. So, in our documentation, there is a section called glossary and you’ll find there the terminology used by the REST v2 API, meaning that we are using profiles and decisions. There is no endpoint that returns a token for the REST v2. So, yeah, I mean, you can please use the ÃÛ¶¹ÊÓƵ website in order to test these endpoints and let us know if you see or encounter any issues while using this tool. So, the ÃÛ¶¹ÊÓƵ website is the one used by Greg in the demo displayed earlier.

Next question. Can access enable REST API v2 work on a side-by-side basis until full migration is complete? For example, I saw REST API v2 and Android on access enable SDK or let’s say for iOS app where some users did not update the app and are still using enable SDK before the full decommission end of year. Well, this is part of the, or it’s kind of the same reference to the question is if there is a compatibility or if there is a migration from the existing REST v1 to the REST v2. Currently, there is no such compatibility. So, the REST v2 is using this kind of improved processing based on user profiles and decisions. It’s pretty much under a new pattern or paradigm from the REST v1 and the SDKs. So, yeah, that’s something that will have to be implemented in the REST v2 and it will not migrate something from REST v1.

The next question.

It seems several of us get for one every time service drive configuration when the IFNI has gotten to work if there is a bug. Might be something to look into.

It’s most probably a problem with dynamic client registration, but once again, if you can submit these details via a ticket, it would be easier for us to understand why you are getting the 401 response and identify the issue.

Next question.

Will authentication persist on latest Android iOS access enabler SDKs as they are using DCR or will it be same as v1 API end user has to re-login? Well, so the SDKs, the current SDKs are using a different set of APIs. So, that’s the reason why they are not compatible with the REST v2 implementations. So, REST v2 is providing this set of API, this set of REST endpoints, so they are following the REST recommendations. There is no client component that keeps information on the client side or on the client storage. The idea was to have us to move this kind of logic on our backend and process that information there by contacting the MVPD endpoints. So, yeah, the answer is the same. There is no compatibility at this point between the existing implementations and the REST v2. The migrated applications means that you are going to use the REST v2 endpoints and perform the authentication and authorization flows. And at that point, new profiles are going to be created following successful authentication with an MVPD. New decisions will be generated by calling the MVPD authorization endpoint. So, all this information is specific to the REST v2 implementation and there is no flow to migrate something from SDK or REST v1 implementation.

I’m not sure if there are more questions.

Seems not.

No. One additional thing here, because I see the reference to the the DCR, so just to, well, emphasize this again, the DCR steps remain the same. So, as soon as you have a registered application created in order to be used for REST v2 implementation, then the steps are the same like in REST v1. So, the dynamic client registration API stays the same. There is no change there. As soon as you get the access token, then you can start calling the REST v2 API endpoints.

I think that did this pretty much. Not sure if you have additional questions. Thank you, JD. Before we wrap up, I’d like to thank you for handling the Q&A session.

As we kick off the migration process, we want to ensure you all have all the support you need. In this regard, as previously mentioned, we’ll be opening a Zendesk ticket with a lifespan of say four to six weeks for each of you. Within this ticket, we would like you to share your estimated migration timeline, ask initial questions, or address any concerns you might have. Additionally, if you run into any challenge or need further support from our team during the implementation phase, don’t hesitate to reach out to us via known channels. If needed, there are, of course, plenty of questions. We could arrange in-depth migration meetings to assist you along the way, as we have done so far. I’d like to thank you very much for your participation today. We really appreciate the time you’ve dedicated to joining us. Thank you.