I think your question is not about the implementation but about the style of the RESTful architecture, otherwise fill free to correct me...
So basically the comment of Buddy Yaussy is totally right. You have two options:
1) Access the entity via two different identifiers
GET/DELETE api/externaljobs/:reference
and
GET/DELETE api/jobs/:id
In a RESTful API every entity must have at least one identifier to be addressable, so having two is no problem at all.
2) Let the external client search for the right job
Depending on the technical and business restrictions you have, you could dictate that the external client has to search for the right job before he is able to delete it.
this could work via
GET api/jobs?reference=1337
get the result:
<job>
[...]
<id>1234</id>
</job>
and with the result of that call
DELETE api/jobs/1234
(you could also just allow DELETE
on job collections, so the external client would be able to call DELETE api/jobs?reference=1337
and would not have two send two calls)
I personally like the second approach much more, because it looks much cleaner because everything you want is possible with basic HTTP methods and you still have just one representation of the job entity, but both of them are acceptable in a RESTful API and depend on "REST design taste" style I think.
Here are three other SO question to look into:
RESTful API behavior for entitys with two independent primary keys
REST API DESIGN - Getting a resource through REST with different parameters but same url pattern
Different RESTful representations of the same resource