Part of the challenge is that "As a user" doesn't tell me who this is for, so it is hard to say if it is valuable. If it is "As a developer of 3rd party websites" then yes, REST API would be an independently-valuable. However, if it is "As a prospective car buyer" then it is certainly not independently-valuable.
To take this further, let's say it is the second option. Now I'd ask why it needs to be split. Are you just putting in your name and sending a message to the dealership? If this is more than a week of work, then there are probably other conversations about the complicated architecture or development process that need to be resolved before the team can reasonably try to complete backlog items in a shorter time frame.
Now, let's say it's more complicated. Perhaps there is a map that they select the dealership from, it pulls their schedule, then you reserve time on that schedule and it updates it with your appointment. Now we can split in some interesting ways. For example, seeing a dealership's schedule (and in particular, when is a good time) is potentially valuable for a car buyer by itself, so I'd look to deliver that as a full feature. If that is too complicated too, perhaps just pulling the schedule from one dealership or a subset is still valuable to some user set.
Alternatively, you could build a request form that emails to the dealership and later connected it through an API. There's an interesting nuance here because the followup backlog item is building the API but because it's building on the existing request, it does deliver value.
It is also worth pointing out that knowledge value is just as important as realized value from a user. Sometimes taking a first pass as some feature and putting it in front of potential users gives you a better idea of the "best" way to implement the feature.
One last thought: Ideally, each team has the ability to deliver any feature completely with just the people in the team. In most cases, this is absolutely possible, it just requires people to branch out of rigidly-defined roles and responsibilities. There are some industries where this isn't possible or you may simply find that it isn't possible YET. If you find yourself in this situation, then it is important for those different teams to create a strategy to work together more collaboratively. I should stress that if you are practicing Scrum, those teams should be working together to finish the backlog item in one sprint.
